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Executive  Summary 


In  view  of  the  Army's  rapidly  increasing  use  of  high 
technology  electronics  in  prime  and  support  systems  as  well  as 
constantly  shrinking  manpower  and  skill  levels.  Automatic  Test 
Equipment  (ATE)  is  now  a  mandatory  element  in  maintenance 
concepts  and  strategies.  Control  of  costs  related  to  the 
utilization  of  ATE  is  of  major  concern  as  is  the  effectiveness  of 
the  maintenance  plan.  Reducing  the  proliferation  of  ATE  within 
the  Army  is  being  addressed;  however,  the  most  significant  cost 
driver  in  ATE  systems  is  ATE  software  -  specifically  Test  Program 
Sets  (TPS's) . 

This  document  recommends  the  implementation  of  a  Pilot  ATE 
Software  Development  and  Support  Facility  for  the  Army.  Such  a 
facility  will  provide  the  mechanism  needed  to  establish  controls 
over  the  TPS  life  cycle  as  well  as  systematize  the  processes 
associated  with  TPS  acquisition,  development  and  post-deployment 
support.  The  objective  is  to  field  performance-effective  and 
supportable  TPS's  at  minimum  life  cycle  costs. 

Standardization  to  the  extent  that  is  possible  and 
economically  beneficial  is  necessary  throughout  the  TPS  life 
cycle.  Simplification  of  the  acquisition  process  is  also  required. 
The  Facility  discussed  within  this  document  will  be  the  vehicle 
for  many  technical  innovations  and  mechanisms  which  will  provide 
a  dramatic  savings  in  the  life  cycle  costs  of  TPS's  and  ATE 
software  in  general.  In  addition,  through  these  same  mechanisms 
the  performance  effectiveness  of  TPS's  will  be  significantly 
incresed  producing  a  positive  effect  on  prime  system  operational 
readiness. 

The  implementation  of  the  Software  Support  Facility  has  been 
structured  in  such  a  way  as  to  blend  in  with  the  current 
Development  and  Readiness  Command  (DARCOM)  planning  for  Test 
Program  Set  (TPS)  development,  support,  and  control  while  still 
remaining  flexible  enough  to  adapt  during  the  period  of 
evolution.  TPS's  are  the  major  cost  driver  for  Automatic  Testing 
life  cycle  cost.  With  proper  planning  and  use  of  appropriate 
standard  documentation,  programming  tools,  and  programming  aids 
it  will  be  possible  for  the  Army  to  field  higher  quality  TPS  that 
have  been  more  thoroughly  debugged  during  development  as  well  as 
becoming  easier  and  less  costly  to  update. 

The  keys  to  the  success  of  the  Army  Software  Support 
Facility  for  ATE  have  been  defined  in  three  previous  documents: 
the  Concept  Plan,  number  CECOM  80-0157-F,  dated  Sep  82,  the 


Functional  Requirements  Document,  number  DAAK  80-81-C-0157-I I , 
dated  5  Sep  82,  and  the  Preliminary  Design  Specification,  number 
DAAK  80-81-C-0157-IV,  dated  Apr  82.  These  documents  define  the 
various  standards,  tools,  and  aids  that  should  be  available  in 
the  Facility  for  Army-wide  use.  The  concept  for  the  Facility  was 
selected  on  the  basis  of  many  studies  and  plans  developed  by  the 
Army,  Air  Force,  and  Navy  and  partially  implemented  in  the  Navy. 
To  eliminbate  the  expensive  and  time-consuming  process  of 
"reinventing  the  wheel"  the  various  standard  documents, 
programming  tools,  and  aids  were  selected  from  existing,  under 
development  or  planned  development  programs  and  projects  whenever 
possible.  Many  of  the  projects  under  development  and  planned  are 
identified  in  the  Joint  Logistics  Commanders  Subtask  Description; 
these  specific  tasks  have  been  identified  in  the  Functional 
Requirements  Document.  Some  of  the  various  standard  documents, 
programming  tools,  and  aids  are  currently  in  use  by  the  Army  or 
other  Services.  These  have  been  clearly  identified  to  allow  the 
rapid  implementation  of  the  Facility  at  an  affordable  cost. 

The  DARCOM  Test  Program  Set  policy  as  well  as  identification 
of  specific  implementation  organizations  is  currently  undergoing 
changes;  therefore,  it  was  not  possible  to  use  the  final 
guidance.  Nevertheless,  the  most  current  drafts  of  the  policy, 
as  well  as  the  Department  of  the  Army  Test,  Measurement  and 
Diagnostic  Equipment  Action  Team  (DATAT)  report  and  the  Army  Post 
Deployment  Software  Support  (PDSS)  Concept  Plan  (including  major 
Command  messages  on  PDSS  plans)  have  been  reviewed  and  used  in 
the  development  of  the  Implementation  Plan.  Due  to  the  current 
evolution  of  organizational  issues  this  Plan  has  remained  as 
generic  as  possible  regarding  organization.  It  is  necessary  for 
the  overall  Facility  to  be  under  the  control  of  a  single  DARCOM 
agency  to  assure  that  the  various  standard  documents,  programming 
tools,  and  aids  are  developed  and  applied.  The  single  DARCOM 
control  agency  will  be  a  part  of  the  overall  Test,  Measurement 
and  Diagnostic  Equipment  (TMDE)  centralized  management  structure 
established  by  the  commanding  general  of  DARCOM  acting  as  the 
Army  TMDE  executive  agent.  The  actual  implementing  organizations, 
however,  can  be  spread  across  -he  Development  and  Readiness 
commands  as  required  by  DARCOM.  With  the  rapid  communication 
that  is  available  throughout  the  United  States  by  computer  links, 
voice,  and  air  delivery  it  will  even  be  possible  to  have  the 
functions  completed  at  various  geographic  locations  if  the 
evolving  DARCOM  organization  requires  this. 

At  this  time  it  appears  that  most  of  the  standard 
documentation  such  as  regulations,  acquisition  guides,  model 
statements  of  work,  etc.,  as  well  as  cost  prediction  models  will 
be  most  efficiently  operated  by  Development  agencies.  The  actual 
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programming  tools  such  as  automatic  test  program  generators  and 
composition  terminals  can  be  operated  by  Readiness  Command 
activities.  Many  of  the  other  tools  and  aids  such  as 
configuration  status  accounting  can  be  operated  by  either  or  both 
commands.  The  exact  selection  of  location  will  depend  on  the 
workload/  physical  facilities,  and  existing  or  projected 
manpower.  Further  details  are  included  in  later  pages  of  this 
work. 


By  structuring  the  Facility  as  indicated  in  the  preceding 
paragraphs  it  will  be  possible  to  develop  and  operate  the 
Facilities  with  only  limited  additional  manpower  within  the 
commands.  There  will  need  to  be  some  reallocation  of  personnel 
who  are  currently  completing  similar  or  possible  duplicative 
efforts  in  various  programs.  If  these  people  are  also  involved 
in  additional  functions  it  may  not  be  possible  to  transition  them 
completely  to  the  Facilities;  therefore,  new  personnel 
assignments  will  be  required.  This  is  especially  true  during  the 
initial  establishment  and  operation  of  the  Facility  as  extensive 
training  on  the  use  of  the  various  standards,  tools,  and  aids  and 
communication  links  must  be  provided.  The  initial  training  cadre 
will  require  2  to  3  people  for  approximately  1  to  1  1/2  years. 
Many  of  the  tools  and  aids  are  being  developed  by  several 
agencies  as  part  of  prime  system  contracts;  therefore,  with 
centralized  direction  it  will  be  possible  for  one  program/product 
management  office  to  consolidate  requirements  from  others, 
partially  eliminating  duplicative  efforts  and  reducing  cost. 
Thi~,  effort  should  require  2  to  3  people  located  in  a  development 
agency.  The  actual  operation  of  the  Facility  will  require  12  to 
15  people. 

As  of  now  most  of  the  TPS  cost  is  buried  in  the  various 
prime  system  total  costs  and  is  not  highly  visible  but  as  the 
multitude  of  TPS  are  delivered  to  the  Army  and  organic  support  is 
attempted  the  cost  will  become  very  apparent  as  various 
programming  aids  and  tools  must  be  procurred,  operated,  and 
maintained  by  Army  personnel.  Reduction  of  this  proliferation 
will  not  only  reduce  acquisition  costs  but  will  reduce  future 
logistics  costs  for  the  various  tools  and  aids.  The  library  of 
standards,  documents,  tools  and  aids  contained  in  the  Facility 
will  provide  guidance  for  improved  acquisition  of  TPS  and  also 
provide  means  to  verify  the  quality  of  the  TPS.  This  will  make 
it  possible  for  higher  quality  TPS's  to  be  delivered  to  the  field 
through  better  documentation  and  more  complete  debugging  before 
delivery.  This  early  debugging  not  only  improves  the  potential 
for  increasing  the  effectiveness  and  efficiency  of  testing,  but 
it  also  reduces  the  cost  of  reworking  TPS  after  fielding. 


To  aid  in  projecting  budget  requirements  for  the  various 
items  that  will  be  contained  in  the  Facility  a  section  containing 
the  Rough  Order  of  Magnitude  cost  has  been  included  for  items 
that  require  some  development.  The  cost  estimates  have  been 
derived  from  many  sources,  including  the  JLC  Automatic  Testing 
Subtask  Description,  similar  tasks  completed  by  the  joint 
Services,  and  extrapolation  from  existing  programs.  In  all  cases 
the  total  cost  to  complete  the  development  efforts  has  been 
included,  and  quite  often  this  figure  gives  the  appearance  of  a 
cost  that  is  higher  than  what  the  Army  must  pay.  This  is  because 
the  Air  Force  and  Navy  are  currently  scheduled  to  fund  all  or 
part  of  the  development  work  as  defined  in  the  JLC  Plan. 
Also  substantially  more  money  than  this  will  be  spent  by  the 
various  prime  system  program  offices  on  similar  or  possibly 
duplicative  tasks.  The  actual)  cost  is  difficult  to  obtain  as  it 
is  buried  so  far  down  in  the  work  breakdown  structure  of  the 
prime  system  cost.  The  total  figures  were  included  to  show  the 
additional  cost  the  Army  will  need  to  absorb  if  the  other 
Services  do  not  complete  the  projects  as  required. 

The  overall  impact  of  implementing  the  Facility  and  making 
all  the  identified  standard  documents,  programming  tools,  and 
programming  aids  available  will  be  to  deliver  high-quality  and 
supportable  TPS  to  the  field  and  to  adequately  maintain  the  TPS 
at  an  affordable  cost.  The  result  of  inaction  will  be  the 
continued  proliferation  of  various  tools  and  aids  with  their 
duplicative  cost  as  well  as  the  difficulty  of  maintaining  and 
improving  the  TPS  after  delivery.  The  quantity  and  rate  of  TPS's 
entering  the  Army  inventory  is  increasing  rapidly;  therefore,  the 
longer  it  takes  to  provide  to  Army  program  offices  and 
contractors  the  various  standards,  tools,  and  aids  contained  in 
the  Facility,  the  opportunity  to  improve  TPS  effectiveness  and  to 
control  cost  will  be  missed  on  many  programs. 


1.0  INTRODUCTION 


1.1  Purpose 

^The  purpose  of  this  study  report  is  to  establish  a  viable 
baseline  plan  for  the  design  of  the  CJ.S.  Army  proposed  ATE 
Software  Development  and  Support  Facilities.  These  facilities 
will  be  utilized  to  effect  controls  over  the  Test  Program  Set 
(TPS)  life  cycle,  provide  dramatic  cost  savings  over  the  TPS  life 
cycle,  and  significantly  increase  the  effectiveness  of  deployed 
Automatic  Test  Equipment  (ATE)  systems. 

Maintenance  requirements  are  rapidly  changing  and  management 
must  plan  to  meet  these  critical  needs.  Planning  efforts  must 
address  the  total  spectrum  of  needs.;  New  or  revised  policy  and 
procedures  must  be  promulgated  to  institutionalize  the  ne* 
maintenance  strategies.  These  maintenance  strategies  mus 
’  address  emerging  technology  and  consider  operational  needs. 

\ 

>  Planning  to  support  the  ATE  Software  Development  and  Suppoi 
Facilities  included  the  development  of  several  plans.  A  Concept 
Plan  sets  forth  the  notion  of  these  Facilities  and  documents  the 
need  for  their  relative  functional  capabilities.-  The  concept 
will  also  illustrate  how  these  Facilities  fit  into  the  general 
operational  scheme  of  prime  system  and  support  system 
acquisition.  '-^A  Functional  Requirements  Document  formally 
establishes  theirfunctions^of  the  ATE  Software  Development  and 
Support  Facility ^nd  provides  a  basis  for  the  mutual 
understanding  between  users  and  designers  regarding  the 
definition  of  this  Facility.  In  addition,  a  Design  Specification 
defines  the  required  equipment  and  resources  including  hardware, 
and  software,  and  personnel  needed  to  complement  the  concept. 
This  Implementation  Plan  provides  a  generic  description  of  the 
organization  needed  to  implement  the-^.S.  Army  Proposed  Automatic 
Test  Equipment  Software  and  Development ^Facility  that  can  be 
tailored  to  match  the  Development  and  Readiness  Command  (DARCOM) 
TPS  policy  and  organization.  The  report  also  places  the 
recommended  projects  into  categories  of  technology  and 
development  with  a  further  breakout  of  short  term  and  long  term. 
To  aid  in  budget  planning,  a  Rough  Order  of  Magnitude  cost 
estimate  has  also  been  included. 
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1.2  Approach 

There  are  several  objectives  for  this  study  effort.  They 
are  as  follows: 

a.  Validate  the  need  for  an  ATE  Software  Development  and 
Support  Facility 

b.  Establish  a  dialogue  with  Army  activities  involved  in 
the  TPS  life  cycle 

c.  Determine  che  impact  of  emerging  systems  on  current 
methods  of  maintenance 

d.  Assess  the  technology  required  to  support  such  a 
concept 

e.  Evaluate  alternative  approaches  and  examine  other 
military  solutions 

In  order  to  satisfy  these  objectives,  the  study  team  visited 
several  Army  organizations  which  are  cognizant  over  some  process 
within  the  TPS  life  cycle.  The  study  team  also  visited  Army 
contractor  facilities  as  well  as  Air  Force  and  Navy 
organizations.  Further,  the  study  team  evaluated  a  variety  of 
reports  concerning  the  issues  related  to  TPS  life  cycle 
management.  Among  these  reports  are: 

a.  Joint  Logistics  Commanders  (JLC)  Panel  on  Automatic 
testing 

b.  U.S.  Air  Force  Mate  Guides 

c  Industry/Joint  Services  Report  on  Automatic  Testing 

d.  Naval  Sea  Systems  Command  (NAVSEA) /Naval  Electronic 
Systems  Command  (NAVELEX)  ATE/TPS  Coordination 
Center  Program  Reports 

e.  Various  DARCOM  plans  and  policy  letters  for  Post 
Deployment  Software  Support  (see  Concept  Plan, 
appendix  C) 

f.  Army  Test  Program  Set  (TPS)  Management  Plan,  draft 
15  July  82 

g.  Department  of  the  Army  Test  Measurement  and 
Diagnostic  Equipment  Action  Team  (DATAT)  Final 
Report,  April  82 


1.3  Results 

This  study  has  confirmed  that  due  to  changing  maintenance 
requirements,  current  assets  must  be  upgraded.  To  accurately 
assess  the  true  maintenance  needs  a  Workload  Analysis  (WLA)  must 
be  performed  to  adequately  scope  hardware,  facilities,  capital 
plant  equipment  and  personnel  needs.  The  WLA  needs  to  be 
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performed  on  a  continuing  basis  to  ensure  and  justify  an  adequate 
support-oriented  asset  base.  Further,  management  support  for 
maintenance  technology  needs  to  be  centralized  to  maintain  pace 
with  the  rapidly  changing  technological  requirements. 

A  dialogue  has  been  established  with  a  variety  of  Army 
activities  involved  in  electronic  maintenance.  This  dialogue  has 
been  fruitful.  All  visits  and  meetings  have  resulted  in  the 
acceptance  of  the  ATE  Software  Development  and  Support  Facility 
concept.  These  activities  have  also  identified  the  need  for  more 
efficient  tools  concerning  TPS  development  and  maintenance. 
Among  the  items  identified  as  essential  are  the  establishment  of 
a  corporate  memory  of  prior  TPS  development  efforts,  through 
standard  documents,  directives  and  trained  personnel,  as  well  as 
providing  the  means  to  maintain  and  track  the  configuration  of 
the  developing  and  deployed  TPS's  with  an  automated  Configuration 
Status  Accounting  System  (CSAS). 


2.0  ORGAN I Z AT I ON /LOCATION 

The  O.S.  Army  proposed  ATE  Software  Development  and  Support 
Facility  has  been  defined  in  the  Concept  Plan,  Functional 
Description  Document,  and  Preliminary  Design  Specification  with 
this  Implementation  Plan  defining  how  the  Facility  may  be 
structured.  The  commanding  general  of  the  Development  and 
Readiness  Command  (DARCOM)  has  been  designated  as  the  D.S.  Army 
executive  agent  for  Test,  Measurement  and  Diagnostic  Equipment. 
In  this  role  he  has  established  a  centralized  management 
structure  to  develop  and  support  all  TMDE.  The  centralized 
development  of  TMDE  has  been  concentrated  within  the  Office  of 
the  Program  Manager,  Test,  Measurement  and  Diagnostic  Equipment. 
This  program  management  office  will  provide  the  centralized 
direction  necessary  to  develop  and  acquire  the  various  standard 
documents,  programming  tools  and  aids  that  will  be  included  in 
the  Facility.  The  actual  operation  of  the  Facility  will  be 
conducted  by  other  Development  and  Readiness  activities. 

Headquarters  DARCOM  established  a  Test  Program  Set  (TPS) 
Management  Plan  Task  Force  in  early  1982  to  define  these  roles. 
To  assure  early  dissemination  of  the  information  contained  in 
this  Plan  and  to  permit  a  framework  for  development  of  the 
various  identified  products  the  TMDE  Program  Management  Office 
has  elected  to  release  this  Plan  prior  to  completion  of  the  TPS 
Task  Force  deliberations.  The  various  Facility  documents  have 
been  structured  to  be  compatible  with  the  new  TPS  policy  and 
organization  responsibilities  that  will  be  defined  by  the  task 
force. 


» 
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The  Facility  will  provide  access  to  all  the  standard 
documents,  programming  tools,  and  aids  for  all  Users  (government 
and  government  contractors);  however,  the  actual  application  of 
the  products  will  be  provided  by  the  using  personnel.  The 
Facility  can  be  considered  as  a  library  that  provides  its 
products  through  communication  links  to  various  organizations. 
Application  of  this  concept  will  allow  the  maximum  use  of  the 
various  products,  thereby  reducing  the  need  for  each  organization 
to  develop  costly  duplicative  products.  Centralized  location(s) 
for  the  Facility  will  also  reduce  the  manpower  needs.  The  Naval 
Electronics  Engineering  Center's  operation  of  a  centralized 
automatic  test  program  generation  facility  has  demonstrated  the 
facility  concept  on  a  limited  scale. 

With  the  easy  availability  of  rapid  communication  links 
through  computers,  telephone,  and  airlift  it  will  even  be 
possible  to  split  the  Facility  into  different  geographic 
locations  if  required  by  DARCOM.  The  most  obvious  products  to 
split  are  the  programming  aids  that  require  extensive 
communication  time;  therefore,  some  of  the  equipment  could  be 
located  on  the  east  coast  while  the  remainder  is  located  on  the 
west  coast. 
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3.0  IMPLEMENTATION  PROJECTS  AND  ROM  COST  ESTIMATES 


The  U.S.  Army  proposed  ATE  Software  Development  and  Support 
Facility  Concept  Plan  in  conjunction  with  the  Functional 
Requirements  Document  provides  a  description  of  the  various 
standard  documentation,  programming  aids  and  programming  tools 
that  should  be  included  in  the  Facility.  The  preliminary  Design 
Specification  defines  how  the  hardware,  software,  and  documents 
are  to  be  installed  in  one  or  more  Facilities  as  well  as  how  the 
communication  network  connects  the  Osers  with  the  Library.  These 
three  documents  should  be  consulted  for  details  that  are  not 
contained  in  this  Implementation  Plan. 

To  obtain  payoff  from  the  Facility  it  is  not  necessary  for 
all  of  the  contents  to  be  in  place;  therefore,  to  begin  receiving 
the  maximum  payoff  from  the  Facility,  work  can  be  done 
incrementally  by  establishing  a  prototype  Facility  by  first 
collecting  all  of  the  existing  identified  documents,  tools,  and 
aids  immediately.  These  items  will  then  be  available  to  all  the 
Users  at  an  early  date.  Concurrent  with  this  effort  the  work  can 
begin  on  development  of  the  new  technology  items  as  well  as 
continuing  or  starting  full  scale  development  and  modification  on 
the  remaining  products. 

The  following  three  subsections  (3.1,  3.2,  and  3.3)  break 
the  products  into  the  various  categories  for  clarity. 


3.1  Existing  Items, 

Many  of  the  library  contents  identified  in  the  Concept  Plan 
paragraph  2.2  are  currently  available  in  the  Army,  Air  Force,  or 
Navy  and  should  be  made  available  immediately  through  the 
Facility  to  all  Army  Users.  By  starting  immediately  with  these 
products  it  will  be  possible  to  incrementally  build  up  the 
contents  of  the  Library  while  developing  the  necessary 
communication  links,  operating  procedures,  and  training  courses. 
As  discussed  earlier,  the  organization  that  provides  centralized 
control  of  the  Facility  as  well  as  the  implementing  organizations 
will  be  directed  by  the  DARCOM  Commander  as  the  U.S.  Army 
Executive  Agent  for  TMDE. 

In  some  cases  more  than  one  version  of  the  various  TPS 
documentation,  aids,  and  tools  exists  within  the  Services  and 
should  be  collected  for  inclusion  in  the  Library.  It  may  be 
desirable  to  include  two  or  more  versions  in  the  Library  until 
the  preferred  version (s)  can  be  identified  through  use  or  command 


decision.  As  these  products  already  exist  the  cost  to  include 
multiple  versions  will  be  minimal. 

The  following  subparagraphs  define  where  the  products  may  be 
obtained  as  well  as  referencing  the  appropriate  Concept  Plan 
paragraph  numbers  where  additional  details  may  be  obtained. 


3.1.1  Standard  Documentation 

(a)  Test  Requirement  Document  (TRD)  Standard  (Concept  Plan 
paragraph  2.2.1  (d)  -  A  new  NIL  Std  1519B  has  been  reviewed  by 
the  JLC  Automatic  Testing  Panel  and  is  now  receiving  formal  joint 
service  review.  The  Draft  document  should  be  provided  at  this 
time  bor  information  as  it  will  aid  in  obtaining  better  and  more 
maintainable  TPS. 

(b)  ATLAS  Standards  (Concept  Plan  paragraph  2.2(h))  -  The 
hardbound  copies  of  the  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE)  Standards  should  be  placed  in  the  Library. 
Copies  may  be  obtained  from  the  O.S.  Navy  Document  Center  in 
Philadelphia  or  by  direct  purchase  from  the  IEEE.  Since  DOD  has 
adopted  Common  ATLAS  as  the  standard  for  use  on  DOD  programs, 
IEEE  Std  716  Common  ATLAS  and  IEEE  Std  717  Common  ATLAS  Formal 
Syntax  should  be  obtained  immediately  and  various  Facility  Dsers 
should  be  notified  of  the  procedures  to  obtain  individual  copies. 
The  Naval  Air  Engineering  Center,  Lakehurst  NAS,  NJ,  is  working 
with  IEEE  to  provide  the  Common  ATLAS  on  a  computer  disc  to  all 
Users . 

(c)  Other  Languages  (Concept  Plan  paragraph  2.2 (i))  -  Due 
to  its  widespread  use  the  documentation,  as  well  as  training 
courses,  for  EQUATE  ATLAS  should  be  included  in  the  Library. 

(d)  TPS  Configuration  Management  Plan  (Concept  Plan 
paragraph  2.2  (j))  -  Tobyhanna  Army  Depot  has  developed  a  model 
TPS  Configuration  Management  Plan  that  is  currently  available. 
The  Air  Force  MATE  Program  Office,  ASD/AEGB,  Wr ight-Patterson 
APB,  OH,  45433,  also  has  developed  a  CM  Plan  that  will  meet  Army 
needs  with  minimum  tailoring. 


3.1.2  Programming  Aids 

(a)  CAD  for  »  'Concept  Plan  paragraph  2.3  (i))  -  Many 
Computer  Aid  Desig  >  software  packages  are  available.  The 

Army  should  obtain  .  f  them  that  are  currently  being  used 

by  prime  system  con-’  s  and  paid  for  by  the  Army. 
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(b)  Word  Processor  (Concept  Plan  paragraph  2.3  (t))  - 
Numerous  word  processors  are  being  used  in  the  Army.  The 
Facility  should  obtain  one  that  will  permit  transfer  of  data  to 
various  Users.  The  Facility  should  be  able  to  transfer  data  to 
different  media  and  different  formats  to  enhance  the  distribution 
of  documents.  The  Navy  and  Air  Force  (Lakehurst  NAS,  NJ,  Wright 
Patterson  AFB,  Oh.  and  Kelly  AFB,  TX)  are  successfully  using 
small  commercial  microprocessor  systems. 

3.1.3  Programming  Tools 

(a)  Digital  ATPG  (Concept  Plan  paragraph  2.4  (a))  - 
Several  Automatic  Test  Program  Generators  (ATPG's)  are  currently 
being  used  by  Tobyhanna  and  Sacramento  Army  Depots.  These 
systems  can  be  tied  into  the  Facility  communication  network  for 
interim  use  on  a  time  share  basis.  Additional  ATPG  capability 
will  have  to  be  placed  in  the  Facility  as  soon  as  possible.  The 
new  equipment  will  be  used  in  the  development  programs  rather 
than  purchasing  new  ones  for  each  prime  system  program  or 
contractor.  The  additional  ATPG  time  will  also  be  qvailable  for 
maintaing  the  deployed  TPS's.  It  may  be  possible  to  arrange  some 
time  sharing  with  the  Naval  Air  Engineering  Center  ATPG  Facility 
both  to  share  their  services  initially  and  in  turn  provide  them 
future  expansion. 

(b)  Digital  Simulator  (Concept  Plan  paragraph  2.4  (b) )  - 
The  same  comments  as  listed  for  the  ATPG's  apply  to  the 
simulators. 

(c)  Text  Editor  (Concept  Plan  paragraph  2.4  (e))  - 
Numerous  Text  Editors  are  being  used  by  the  Army  and  their 
contractors.  Standardized  versions  should  be  selected  and  placed 
in  the  Facility. 

(d)  RCA  EQUATE  ATLAS  Compiler  and  Syntax  Checker  (Concept 
Plan  paragraph  2.4(g))  -  Appropriate  versions  of  the  EQUATE 
Compiler  and  Syntax  Checker  and  documentation  used  on  the  AN/USM- 
410  should  be  included. 

(e)  Other  Compilers  and  Syntax  Checkers  (Concept  Plan 
paragraph  2.4  (h))  -  Compilers  and  syntax  checkers  used  on  ATE  by 
more  than  one  Army  program  and  which  will  be  used  in  the  future 
should  be  included  in  the  Facility.  Examples  of  the  ATE  are  the 
Genrad  2225,  STE/ICE,  etc. 
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(£)  EQUATE  TPS  Generation  Station  (Concept  Plan  paragraph 
2.4  (o))  -  The  TPS  generation  station  developed  by  Tobyhanna  Army 
Depot  should  be  provided  to  other  Users  through  the  Facility 
Communication  Network. 


3.2  Technology  Projects 

Items  listed  in  this  section  of  the  report  are  the  various 
programming  aids  and  programming  tools  that  will  require  some 
technology  work  before  they  are  transistioned  to  full  scale 
development.  Under  the  current  DARCOM  organization  it  is 
anticipated  that  the  Army  Test  Measurement  and  Diagnostic 
Technology  Laboratory  (ATTL)  will  provide  the  centralized 
direction  for  these  projects.  In  reality,  the  actual  completion 
of  the  projects  may  be  carried  out  by  various  Army  organizations 
as  reflected  in  the  Army  Test,  Measurement  and  Diagnostic 
Technology  team.  To  further  aid  in  planning  the  projects  they 
are  divided  into  two  categories:  rapid  payoff  technology  (less 
than  two  years  to  transition  to  development)  and  longer  term 
technology  (more  than  two  years  to  transistion  to  development). 
The  following  subparagraphs  list  the  various  projects  as  well  as 
identifying  the  Concept  Plan  paragraph  number  where  additional 
information  may  be  obtained  on  the  project.  If  the  project  is 
also  covered  by  the  Joint  Logistics  Comammanders  .JLC)  Automatic 
Testing  Plan,  the  Air  Force  Modular  Automatic  Test  Equipment 
(MATE)  Program,  or  the  Navy  Consolidated  Support  System  (CSS) 
Program  it  also  will  be  noted. 

The  following  section  contains  some  Rough  Order  of  Magnitude 
(ROM)  cost  estimates  for  the  various  technology  projects  that 
have  been  identified.  The  ROM  cost  estimate  has  been  arrived  at 
by  comparing  similiar  programs  and  also  from  estimates  contained 
in  the  JLC  Automatic  Testing  Plan  Subtask  description.  In  many 
cases  some  of  this  cost  has  already  been  allocated  by  other 
services;  therefore,  the  cost  to  the  Army  will  be  reduced.  To 
assure  duplicative  tasks  are  not  completed  by  the  services  it  is 
important  that  tasks  identified  as  JLC  or  those  that  are  listed 
as  MATE,  CSS  or  ongoing  Army  be  closely  coordinated  by  the 
apporopriate  Army  Program/Project  Management  Office.  The  close 
coordination  will  help  the  Army  Program/Project  Management  Office 
obtain  the  various  products  earlier  and  cheaper  than  "going-it- 
alone".  The  other  services  may  be  able  to  assist  in  funding 
projects  that  the  Army  establishes  under  the  JLC  Automatic 
Testing  Plan. 
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3.2.1  Rapid  Payoff  Technology  Projects 


3. 2. 1.1  Programming  Aids 

(a)  TPS  Quality  Assurance  Tools  (Concept  Plan  paragraph 

2.3  (1)) 


FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000' s 

180 

220 

60 

44 

48 

552 

(b) 

Graphics  Development  Aids 

(Concept 

Plan 

paragraph 

2.3  ( j) ) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000's 

40 

30 

26 

30 

32 

158 

3.2. 1.2  Programming 

Tools 

(a) 

ATLAS 

Flow  Chart 

Generator 

(Concept 

Plan 

paragraph 

2.4  (d)) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000 ' s 

100 

200 

300 

(b) 

ATLAS 

Composing 

Terminal 

(Concept 

Plan 

paragraph 

2.4  (k)) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000* s 

700 

1500 

1000 

3200 

3.2.2  Longer  Term  Payoff  Technology  Projects 


3. 2. 3.1  Programming  Aids 


(a) 

2.3  (j)) 

Graphics 

Development  Aids 

(Concept 

Plan 

paragraph 

FISCAL  YEAR 

84 

85  86 

87 

88 

TOTAL 

$  in  1000 *s 

160 

120  104 

120 

128 

632 

(b)  TPS  Fault  Isolation  Models  (Concept  Plan  paragraph 

2.3  (k)) 

FISCAL  YEAR  84  85  86  87  88  TOTAL 

$  in  1000 ' s  220  250  350  290  250  1360 


3. 2. 3. 2  Programming  Tools 

(a)  Analog  ATPG  (Concept  Plan  paragraph  2.4  (c)  and  JLC 
Automatic  Testing  Plan  30508) 

FISCAL  YEAR  84  85  86  87  88  TOTAL 

$  in  1000 '  s  150  700  1580  1300  900  4630 


(b)  Self  Improving  ATE/TPS  (Concept  Plan  paragraph  2.4 
(1)  and  JLC  Automatic  Testing  Plan  30508) 

FISCAL  YEAR  84  85  86  87  88  TOTAL 

$  in  1000 's  200  1200  4000  700  400  6500 


(c)  Failure  Modes  Effects  Analysis  (FMEA)  to  ATLAS 
Translator  (Concept  Plan  paragraph  2.4  ( j ) ) 

FISCAL  YEAR  84  85  86  87  £8  TOTAL 

$  in  1000  *  s  100  230  390  290  320  1330 


3.3  Development  Projects 

Items  listed  in  this  section  of  the  report  are  the  various 
programming  aids,  programming  tools  and  standard  documentation 
that  will  require  some  development  work  before  they  are 
implemented.  Under  the  current  DARCOM  organization  it  is 
anticipated  that  the  Product  Manager  Automatic  Test  Support 
System  (PM,  ATSS)  will  provide  the  centralized  direction  for 
these  projects.  In  reality,  the  actual  completion  of  the 
projects  may  be  carried  out  by  various  Army  program/product 
management  offices.  To  further  aid  in  planning  the  projects  they 
are  divided  into  two  categories:  rapid  payoff  development  (less 
than  2  two  years  to  completion)  and  longer  term  payoff 
development  (over  two  years  to  completion).  The  following 
subparagraphs  list  the  various  projects  as  well  as  identify  the 
Concept  Plan  paragraph  number  where  additional  information  may  be 
obtained  on  the  project.  If  the  project  is  also  covered  by  the 


Joint  Logistics  Comammanders  (JLC)  Automatic  Testing  Plan,  the 
Air  Force  Modular  Automatic  Test  Equipment  (MATE)  Program,  or  the 
Navy  Consolidated  Support  System  (CSS)  Program  it  also  will  be 
noted. 


The  following  section  contains  some  Rough  Order  of  Magnitude 
(ROM)  cost  estimates  for  the  various  development  projects  that 
have  been  identified.  The  ROM  cost  estimate  has  been  derived  by 
comparing  similar  programs  and  also  from  estimates  contained  in 
the  JLC  Automatic  Testing  Plan  Subtask  description.  In  many 
cases  some  of  this  cost  has  already  been  allocated  by  other 
services;  therefore,  the  cost  to  the  Army  will  be  reduced.  To 
assure  duplicative  tasks  are  not  completed  by  the  services  it  is 
important  that  tasks  identified  as  JLC  or  those  that  are  listed 
as  MATE,  CSS  or  ongoing  Army  be  closely  coordinated  by  the 
appropriate  Army  Program/Project  Management  Office.  The  close 
coordination  will  help  the  Army  obtain  the  various  products 
earlier  and  cheaper  than  "going-it-alone."  The  other  services 
may  be  able  to  assist  in  funding  projects  that  the  Army 
establishes  under  the  JLC  Automatic  Testing  Plan. 


3.3.1  Rapid  Payoff  Development 

3. 3. 1.1  Programming  Aids 

(a)  TPS  LCC  Prediction  Model  (Concept  Plan  paragraph  2.3 
(a),  JLC  Automatic  Testing  Plan  20402,  30101,  and  MATE) 


FISCAL  YEAR 

84 

85 

86 

87 

11 

TOTAL 

$  in  1000's 

30 

30 

(b) 

TPS 

Development 

Cost  Models  (Concept 

Plan 

paragraph 

2.3  (b),  JLC 

Automatic  Testing 

Plan 

30101,  CECOM, 

and 

MATE) 

FISCAL  YEAR 

84 

85 

86 

12 

11 

TOTAL 

$  in  1000  's 

40 

40 

(c) 

TPS 

Schedule  and 

Cost 

Tracking  System  (Concept  Plan 

paragraph  2. 

3  (c). 

and  MATE) 

FISCAL  YEAR 

84 

85 

86 

12 

11 

TOTAL 

$  in  1000* s 

40 

40 

15 


(d)  TPS  Acquisition  Data  Collection  System  (Concept 
Plan  paragraph  2.3  (f),  and  MATE) 


FISCAL  YEAR  84 

$  in  1000's  60 


TOTAL 

90 


3. 3. 1.2  Programming  Tools 

(a)  IEEEE  Std  716  Common  ATLAS  Compiler  and  Syntax 
Checker  (Concept  Plan  paragraph  2.4  (f),  JLC  Automatic  Testing 
Plan  30111,  CECOM,  NAEC,  and  MATE) 


FISCAL  YEAR 
$  in  1000' s 


TOTAL 

500 


(b)  Test  Program  Development  Stations  (Concept  Plan 
paragraph  2.4  (m) ) 


FISCAL  YEAR  84 

$  in  1000 '  s  1000 


TOTAL 

1800 


3. 3. 1.3  Standard  Documentation 

(a)  Facility  Users  Guide  and  Training  Courses  (Concept 
Plan  paragraph  2.2  (a)) 


FISCAL  YEAR 
$  in  1000 's 


TOTAL 

115 


(b)  TPS  Acquisition  Guide  (Concept  Plan  paragraph  2.2 
(b),  JLC  Automatic  Testing  Plan  20503,  20504,  20801,  and  MATE) 


FISCAL  YEAR 
$  in  1000* s 


TOTAL 

85 


(c)  Design  for  Testability  Guide  (Concept  Plan 
paragraph  2.2  (c),  JLC  Automatic  Testing  Plan  20302,  and  MATE) 


FISCAL  YEAR 
$  in  1000' s 


TOTAL 

400 


(d)  Model  UDT  Test  Requirement  Document  (TRD)  Statement 
of  Work  (SOW)  (Concept  Plan  paragraph  2.2  (e) ,  and  MATE) 
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FISCAL  TEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000 's 

30 

30 

(e) 

Model  TPS 

SOW  (Concept 

Plan  paragraph  2. 

.2  (f),  JLC 

Automatic  Testing  Plan 

10201, 

10202, 

and  MATE) 

FISCAL  TEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000 ' s 

20 

20 

(£) 

Model  TPS 

Specification 

(Concept 

Plan  paragraph  2.2 

(g) ,  JLC  Automatic  Testing  Plan 

20304 

and  MATE) 

FISCAL  TEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000* s 

70 

20 

90 

(g) 

Model  TPS 

Integrated  Logistics  Support 

(ILS)  Plan 

(Concept  Plan 

paragraph 

2.2  (k) 

,  and 

MATE) 

FISCAL  TEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000  * s 

20 

20 

(h)  Model  TPS  Quality  Assurance  Plan  (Concept  Plan 
paragraph  2.2  (1),  and  MATE) 


FISCAL  YEAR 
$  in  1000' s 

84 

20 

85 

86 

87 

88 

TOTAL 

20 

(i) 

paragraph  2.2 

Model  TPS  Request 
(m) ,  and  MATE) 

for 

Proposal 

(RFP)  (Concept  Plan 

FISCAL  YEAR 
$  in  1000' s 

84 

30 

85 

86 

87 

88 

TOTAL 

30 

(j) 

JLC  Automatic 

TPS  Style  Guide  (Concept  Plan  paragraph 
Testing  Plan  20501,  and  Tobyhanna) 

2.2  (n). 

FISCAL  YEAR 
$  in  1000*8 

84 

30 

85 

86 

87 

88 

TOTAL 

30 
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3.3.2  Longer  Term  Payoff  Development  Projects 
3. 3. 2.1  Programming  Aids 


(a)  DOT  Failure  Data  Collection  System  (Concept  Plan 


paragraph  2.3 

(d),  MATE,  and  CSS) 

FISCAL  TEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000's 

70 

40 

110 

(b) 

ATE/TPS 

Operations  Data 

Collection 

System 

(Concept 

Plan  paragraph  2.3  (e) 

,  MATE,  and  CSS) 

FISCAL  YEAR 

84 

85 

86 

iZ 

88 

TOTAL 

$  in  1000 's 

70 

40 

no 

(c) 

Library 

of  ATLAS 

Procedures  (Concept 

Plan  paragraph 

2.3  (g)) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000 1 s 

85 

20 

105 

(d) 

Unit  Under  Test 

(UUT)  vs  ATE  and 

Interface  Test 

Adapter  (ITA) 

Matching 

Algorithm  (Concept  Plan  paragraph 

2.3  (h). 

JLC  Automatic 

Testing 

Plan  20601,  and 

MATE) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000' s 

110 

85 

45 

240 

(e) 

TPS  Quality  Assurance  (Concept  Plan  paragraph  2.3 

(1) ,  JLC  Automatic  Testing  Plan 

30110, 

and  MATE) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000  '  s 

720 

880 

240 

176 

192 

2208 

(f) 

Workload 

Analysis 

System 

(Concept  Plan  paragraph  2. 

<»)) 

FISCAL  YEAR 

84 

85 

86 

8_7 

88 

TOTAL 

$  in  1000 's 

140 

80 

30 

250 

(g)  ATE/TPS  Operation  Model  (Concept  Plan  paragraph  2.3 

(n)) 


FISCAL  YEAR 

84 

85 

86 

87 

8J3 

TOTAL 

$  in  1000 's 

110 

50 

160 

(h) 

Depot 

and  General  Support 

(GS)  ATE 

Shop 

Scheduling 

System  (Concept  Plan  paragraph  2.3  (o) , 

and  CSS) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000' s 

120 

50 

170 

(i) 

TPS  Developer 

Configuration  Status  Accouting  System 

( CS AS )  (Concept  Plan  paragraph  2.3  (p) , 

KATE,  and 

CSS) 

FISCAL  YEAR 

84 

8J5 

86 

87 

88 

TOTAL 

$  in  1000 ' s 

150 

80 

230 

(j) 

Army 

TPS  Managers  CSAS  (Concept  Plan  paragraph  2.3 

(q) ,  Tobyhanna 

Army 

Depot,  MATE,  and  CSS) 

FISCAL  YEAR 

84 

85 

87 

88 

TOTAL 

$  in  1000* S 

150 

80 

230 

(k) 

Shop 

Testing 

Capabilities  System 

(Concept  Plan 

paragraph  2.3 

(r)) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000 's 

190 

150 

50 

390 

(1) 

Deficiency  Reporting  and 

Feedback 

System  (Concept 

Plan  paragraph  2.3 

(s)) 

FISCAL  YEAR 

84 

85 

86 

87 

88 

TOTAL 

$  in  1000 ' s 

90 

45 

135 
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3. 3. 2. 2  Programming  Tools 


(a)  Translators  (Concept  Plan  paragraph 

FISCAL  YEAR  84  85  86  87 

$  in  1000 ' s  500  300 


2.4  (i)) 
88 
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4.0  CONCLUSIONS  AND  RECOMMENDATIONS 


In  order  to  upgrade  the  ability  of  the  Army  to  meet  the 
maintenance  challenges  presented  to  them  via  the  new  wave  of 
high-technology  weapons  and  support  systems,  it  is  essential  to 
effect  standardization  on  the  TPS  life  cycle  process.  This 
process  needs  to  be  formally  defined  and  controlled.  The 
acquisition  of  ATE  software  is  full  of  contracting  traps  which 
work  against  the  government.  Procedures  for  TPS  contracting, 
including  Statements  of  Work  specification  preparation  must  be 
simplified  to  a  routine  level  and  facilitated  by  automation. 
Management  information  systems  are  needed  to  guide  the  TPS 
acquisition  process,  create  an  audit  trail,  and  develop  a 
corporate  memory  to  provide  lessons  learned  for  future 
acquisitions . 

There  are  many  software  tools  and  aids  which  are  now  used  to 
simplify  and  automate  the  TPS  acquisition,  development,  and 
maintenance  process;  however,  in  order  to  preserve  the  positive 
effect  these  tools  promise,  they  must  be  benchmarked  and  receive 
formal  approval  and  entry  into  the  Army  standard  family  of  TPS 
tools  and  aids.  Such  a  standard  family  must  be  controlled  so 
that  changes  or  enhancements  do  not  destroy  the  traceability 
required  to  facilitate  TPS  maintenance. 

As  maintenance  strategies  push  sophisticated  ATE  systems 
closer  to  the  front  lines  a  means  for  providing  consistent 
technical  support  to  these  forward  detachments  is  essential. 
Technicians  will  require  a  single  source  for  assistance  relative 
to  their  commodity.  This  will  ensure  the  effectiveness  of  the 
ATE  while  stabilizing  the  morale  of  the  technician. 

It  is  recommended  that  a  pilot  Army  ATE  Software  Development 
and  Support  Facility  be  developed  to  meet  the  requirements  set 
forth  in  this  document  and  the  Concept  Plan,  Functional 
Requirements  Document  and  Preliminary  Design  Specification.  Such 
a  facility  could  serve  as  a  pilot  for  implementation  of  specific 
ATE  software  policy  and  guidance.  Other  facilities  will  emerge 
to  support  increasing  operational  requirements.  All  facilities 
should  be  networked  to  ensure  backup  support  in  case  of 
malfunction,  etc.  The  pilot  Facility  shall  be  the  test  bed  for 
new  standard  documents,  software  tools,  and  programming  aids  and 
will  validate  these  products  in  order  to  accept  them  as  part  of 
the  Army  ATE  software  asset  base.  The  pilot  Facility  will  also 
provide  facilities  to  back  up  all  data  bases  on  line  at  other 
similar  facilities. 
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This  program  should  commence  immediately  by  developing  a 
communciation  network  using  existing  assets  that  are  in  place  or 
that  are  being  procurred.  The  Facility  or  Library  can  be 
available  within  90  days  using  existing  items  identified  in 
section  3.1,  as  well  as  tailoring  the  items  outlined  in  section 
3.2  and  3.3. 
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APPENDIX  A 


Outline 
of  the 

Naval  Sea  Systems  Command  (NAVSEA) /Naval  Electronics  Systems 
Command  (NAVELEX)  Automatic  Test  Equipment  (ATE) /Test  Program  Set 

(TPS)  Coordination  Center 


A  brief  outline  of  the  Navy  TPS  Coordination  Center  being 
developed  by  the  Fleet  Analysis  Center  is  provided  as  general 
information  on  a  similar  concept  that  is  being  developed  to 
support  small  digital  testers. 

Additional  information  may  be  obtained  from: 

Mr.  Jim  Hoote 
Fleet  Analysis  Center 
Code  824 

Corona,  CA  91720 
AV  933-4469 
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APPENDIX  B 


Outline 
of  the 

MATE  TPS  Acquisition  Guide 

A  brief  outline  of  the  content  of  the  MATE  Test  Program  Set 
(TPS)  Acquisition  Guide  is  provided  to  indicate  some  work  that  is 
in  process  or  planned  that  will  provide  many  TPS  acquisition 
documents,  programming  tools  and  aids.  Many  of  these  products 
may  be  easily  tailored  for  Army  use,  permitting  the  ATE  Software 
Development  and  Support  Facility  to  be  established  and  effective 
sooner  at  a  lower  cost. 

Additional  information  may  be  obtained  from: 

Lt  Col  Gene  Jensen 
ASD/AEGB 

Wright-Patterson  AFB,  OH  45433 
AV  785-6612 


VOL  II,  TPS  ACQUISITION  PROCEDURES 


ARE  ADDRESSED  THROUGHOUT  THE  TPS  LIFE 
CYCLE 


VOL  III  TPS  ACQUISITION  AND  SUPPORT  TOOLS 
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S.  A 


1.0  INTRODUCTION 


The  US  Army  proposed  Software  Development  and  Support  Facility  will  serve 
as  a  library  for  many  organizations,  government  and  contractor,  that  are 
engaged  in  specifying,  developing  and  maintaining  test  program  sets.  This 
Facility  may  not  necessarily  support  the  automatic  test  equipment  (ATE) 
operating  system  software.  Throughout  this  document  the  term  test  program  set 
(TPS)  will  mean:  (a)  the  applications  software  or  test  program  (TP)  required 
to  test  a  specific  unit  under  test  (UUT),  (b)  the  interface  test  adapter  (ITA) 
or  interface  device  (ID)  that  is  required  to  mechanically  and  electrically 
connect  the  automatic  test  equipment  (ATE)  to  the  specific  UUT,  (c)  the  test 
program  instruction  (TPI)  which  is  the  documentation  needed  to  operate  and 
maintain  the  TP  and  ITA.  The  Facility  will  contain  all  standard 
documentation,  programming  aids  and  tools  necessary  to  develop  and  maintain 
consistently  high  quality  TPS  at  a  reduced  life  cycle  cost  (LCC).  Through  the 
use  of  computer  communication  links,  telephone,  and  mall  the  Facility  will 
make  available  the  contents  of  the  library  to  many  users.  Many  different  Army 
and  contractor  organizations  will  require  access  to  the  Facility.  The 
different  agencies  Include  those  that: 

(a)  conduct  TPS  acquisition  planning 

(b)  conduct  TPS  acquisition 

(c)  conduct  TPS  development 

(d)  conduct  independent  TPS  validation  and  verification  (VAV) 

(e)  control  and  maintain  the  TPS  after  deployment 

The  proposed  concept  for  an  ATE  software  development  and  support  facility 
is  being  developed  with  organizational  flexibility  as  a  keystone.  The 
Facility  can  function  within  the  current  or  future  organization  structure  of 
various  DARCOM  major  subordinate  commands.  Management  plans  such  as  the  Army 
Post  Deployment  Software  Support  (PDSS)  Plans  were  also  considered  during  the 
development  of  this  concept. 

1.1  Need  for  an  ATE  Software  Development  and  Support  Facility 

During  the  past  several  years  numerous  studies  have  been  conducted  on  all 
aspects  of  supporting  weapon  (prime)  systems  to  Improve  operational 
availability.  In  all  cases  the  most  expensive  (approximately  80S  of  support 
cost)  item  with  the  largest  Influence  on  availability  was  automatic  testing. 
The  single  most  Inclusive  study  was  completed  in  1980  by  five  Industry 
associations  at  the  request  of  DOD.  The  Industry/ Joint  Services  Automatic 
Testing  Project  (I/JSATP)  was  completed  over  a  three-year  period  as  a 
follow-on  to  a  two-year  study  of  Navy  automatic  testing  problems.  The  I/JSATP 
involved  over  800  people  representing  86  corporations,  11  universities  and  all 
the  Services.  The  final  report  was  published  in  June  1980  and  currently  is 
being  briefed  to  all  the  senior  command  personnel  in  all  development  and 
logistic  commands  by  members  of  the  National  Security  Industrial  Association 
(NSIA).  It  provides  eleven  summary  categories  of  problems  and  recommends 
solutions  that  embody  110  specific  recommendations.  The  recommendations  apply 
to  all  the  Services.  Many  of  these  problems  are  being  addressed  by  the 
Services  through  the  Joint  Logistic  Commanders  (JLC)  Automatic  Testing  Panel. 

The  report  indicated  that  DOD  was  annually  spending  in  excess  of 
$3,200,000,000.00  on  automatic  testing.  Software  development  cost  was  over 
half  that  figure.  Of  the  $1,600,000,000  software  cost,  less  than  2X  is 
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attributable  to  the  operating  system  software;  the  reaaining  98Z  to  99. 8Z  la 
spent  on  the  application  software  or  test  programs.  The  Army's  share  of  AT 
cost  at  that  time  was  approximately  $800,000,000  annually;  however,  that  cost 
is  Increasing  very  rapidly.  As  hundreds  of  new,  highly  complex  prime  ayateaa 
enter  the  Army  inventory  the  quantity  of  testing  hardware  and  software  la 
increasing  very  rapidly. 

The  I/JSATP  Report  stated  that:  "With  complexity  and  demand  increasing 
ATE  acquisition  costa,  the  test  program  set  has  emerged  as  probably  the  most 
significant  ATE  cost  driver.  The  nonrecurring  expenses  Involved  in  developing 
the  computer-compatible  automatic  diagnostic  test  programs  have  risen 
significantly  over  the  past  decade.  TPS  cost  control  is  only  part  of  the 
problem,  however.  Test  program  set  quality  and  effectiveness  are  of  equal 
concern.  Unless  a  test  program  set  is  structured  for  the  appropriate 
maintenance  environment,  designed  for  available  personnel  skill  levels,  and 
adequately  validated  prior  to  release  to  the  field,  its  effectiveness  quotient 
will  severely  hamper  the  productivity  and  throughput." 

Implementation  of  the  25  I/JSATP  Report  TPS  related  recommendations  may 
be  activated  through  the  controlled  management  approach  to  test  program  set 
development  and  maintenance  through  the  use  of  the  ATE  Software  Development 
and  Support  Facility.  The  I/JSATP  Report  further  indicates  that  implementing 
these  recommendations  should  reduce  the  recurring  TPS  cost  by  at  least  20Z. 
In  addition  to  the  cost  savings  the  quality  of  the  TPS's  will  Improve, 
therefore  improving  operational  availability  of  the  prime  system. 

In  a  recent  Naval  Sea  Systems  Command  and  Naval  Electronics  System 
Command  Study  that  covered  TPS  generation  for  two  small  digital  card  testers, 
a  substantial  savings  was  predicted.  The  study  application  indicated  that  for 
a  centralized  TPS  facility  versus  unplanned  decentralized  support  a  savings  of 
at  least  $34,000,000.00  will  result  over  a  seven-year  period.  The  I/JSATP 
Report  also  pointed  out  the  following  serious  consequences  of  inaction: 

(a)  continued  high  TPS  acquisition  cost3 

(b)  lengthy  and  frequently  tardy  TPS  development 

(c)  continued  negative  impact  of  nonstandardization  on  TPS  maintenance 

(d)  reduced  prime  system  operational  availability 

In  addition  to  the  increasing  inventory  of  complex  Army  systems,  the  Army 
is  also  facing  two  additional  problems  —  the  reduction  of  manpower  available 
for  service  as  well  as  the  Army  policy  of  keeping  technician  training  to  a 
minimum.  Both  of  these  increase  the  need  for  more  effective  and  efficient 
automatic  testing. 

The  Army's  decision  to  control  the  proliferation  of  ATE  through  the  use 
of  standard  ATE  such  as  the  AN/USM  410  (EQUATE)  across  multiple  weapon  systems 
will  reduce  cost.  However,  this  action  also  requires  the  control  of  the 
Interface  test  adapters  (ITA)  that  are  developed  as  part  of  the  test  program 
sets.  Uncontrolled  proliferation  of  the  ITA's  must  be  reduced.  An  ITA  data 
I  base  can  provide  the  status  of  ITA's  on  specific  programs  so  that  parallel  or 

later  programs  will  not  need  to  develop  new  ITA's.  One  of  the  major  "lessons 
[->  learned"  from  the  Navy's  Versatile  Automated  Shop  Tester  (VAST)  Program  was 

that  selection  of  a  standard  tester  did  not  solve  all  of  the  problems. 
Without  control  of  the  TPS  the  ITA  proliferated  into  large  and  active  devices, 
causing  many  operational  and  support  problems  that  should  have  been 
eliminated. 

Several  years  ago  the  Air  Force  established  six  software  support  centers 
to  maintain  the  weapon  and  prime  system  software.  The  ATE  and  TPS  software 
was  excluded  from  initial  planning;  however,  it  has  since  been  added  to  the 
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software  support  center's  mission.  A  study  conducted  during  the  summer  of 
1981  indicated  that  over  75Z  of  software  support  center's  workload  was 
associated  with  test  programs.  The  original  planning  had  not  considered  that 
hundreds  of  times  as  many  test  programs  would  be  prepared  as  weapon  and  prime 
system  operating  software. 

The  ATE  Software  Development  and  Support  Pacility  will  help  prevent  the 
TPS  software  support  problem  from  becoming  completely  unmanageable  by 
providing  the  necessary  standardized  documentation,  programming  aids  and  tools 
to  aid  in  developing  TPS.  Use  of  the  contents  of  the  library  will  improve  the 
management,  acquisition,  development  and  maintenance  of  test  program  sets. 
Proper  and  complete  use  of  the  Facility  will  result  in  improved  weapon  and 
prime  system  availability  through  improved  fault  detection  and  fault  Isolation 
while  reducing  the  problems  associated  with  fielding  large  numbers  of  complex 
interface  test  adapters. 

1.2  General  Function 


The  general  function  of  the  proposed  ATE  Software  Development  and  Support 
Facility  is  to  provide  a  centralized  library  of  standard  documents  for  TPS 
development  and  maintenance  programming  aids  and  tools.  Access  to  the  library 
will  be  maintained  through  remote  computer  terminals,  telephone  and  mail,  thus 
reducing  the  need  for  many  underutilized  and  duplicative  systems.  Reduction 
in  duplicative  systems  will  save  additional  recurring  cost  based  on  the  number 
of  program  offices,  developers  and  maintainers  chat  will  not  need  to  procure 
duplicative  capabilities. 
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FIGURE  1.  COMMUNICATION  LINKS 


The  function  of  the  library  la  Independent  of  Development  and  Readiness 
Command  ( DARCQM)  organizational  Issues.  It  will  be  able  to  support  the  TPS 
development  for  a  variety  of  prime  system  program  management  offices  as  well 
as  supporting  the  Post  Deployment  Software  Support  (PDSS)  Center  concepts. 
The  number  and  physical  location  of  the  Facilities  should  be  determined  on  a 
workload  analysis  of  the  various  users  or  commodity  commands. 

The  actual  acquisition,  development,  and  maintenance  of  the  TPS’s  will  be 
conducted  by  existing  Army  offices  and  contractors.  However,  the  process  will 
be  enhanced  through  a  small  cadre  of  highly  qualified  people  located  in  the 
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Facilities.  The  cadre  will  maintain  the  library  and  arrange  for  updates  as 
well  as  provide  training  on  the  availability  and  use  of  the  various  documents, 
aids  and  tools  contained  in  the  library. 

Whenever  possible,  the  contents  of  the  library  will  be  selected  from 
existing  projects  or  those  under  development  by  the  Army,  Air  Force  or  Navy. 
In  some  cases  the  existing  products  may  have  to  be  modified  to  provide  a  more 
standardized  product  for  Army-wide  application.  Occasionally  a  new  product 
will  need  to  be  developed  to  improve  the  quality  of  TPS's.  However,  the 
function  of  the  facility  is  not  to  develop  tools  and  aids,  but  to  host  them. 
All  products  will  be  tailored  to  meet  the  needs  of  various  disciplines 
Involved  in  acquisition,  development  and  maintenance  of  TPS.  Representative 
disciplines  are: 

(a)  Program  Management 

(b)  Program  Control 

(c)  Engineering 

(d)  Configuration  Management 

(e)  Data  Management 

(f)  Quality  Assurance 

(g)  Integrated  Logistics  Support 

(h)  Programmers 

(i)  ITA  Fabricators 

( j )  TPS  Maintalners 


1 . 3  Concept  Evolution 

The  concept  evolution  for  the  ATE  Software  Development  and  Support 
Facility  has  followed  a  top-down  successive  refinement  technique.  A  baseline 
concept  was  defined  from  a  top-level  review  of  future  Army  TPS  requirements. 
It  considers  the  nearly  exponential  growth  in  TPS  development  and  support 
resulting  from  the  large  numbers  of  complex  weapon  and  prime  systems  that  are 
beginning  to  enter  the  Army  Inventory.  It  is  also  based  on  a  review  of  all 
DARCOM  major  subordinate  commands  current  and  planned  programs  that  have 
developed,  or  are  developing,  as  well  as  TPS  documentation  standards, 
programming  aids  and  tools.  The  initial  concept  also  is  based  on  a  knowledge 
of  TPS  tasks  being  conducted  under  the  auspices  of  the  Joint  Logistics 
Commanders  Automatic  Testing  Panel,  appendix  B.,  and  related  Air  Force  and 
Navy  projects. 

The  initial  ATE  Software  Development  and  Support  Facility  concept  has 
been  presented  to  several  Army  organizations.  After  each  presentation  active 
discussion  ensued,  resulting  in  additional  items  being  added  to  the  Facility 
and  existing  concepts  being  modified  based  on  the  experiences  of  personnel 
present  at  the  briefings. 

The  concept  is  evolving  through  this  direct  contact  with  Army  personnel 
Involved  in  all  aspects  of  TPS  development  and  support  ranging  from  policy  to 
hands-on  maintenance. 

Many  DOD  and  Army  policies  are  also  being  incorporated  into  the  Facility 
concept.  For  example  the  following  were  considered: 

(a)  DOD  policies  on  automated  data  systems  and  embedded 
computer  management 

(b)  DOD  policy  to  use  IEEE  Std  716-1982  Common  ATLAS  as 
the  programming  language  for  all  future  test  programs 

(c)  the  DARCOM  policy  to  use  the  AN/USM  410  (EQUATE)  for 

all  future  general  support  and  depot  testing  requirements 


The  concept  recognizes  that  a  large  percentage  of  the  TPS  developed 


during  the  next  few  years  will  operate  on  the  AN/USM  410.  However,  in  the 
near  term,  aany  TPS's  will  be  developed  for  other  general  support  (GS)  and 
depot  ATE  that  are  currently  entering  the  inventory.  It  also  recognizes  that 
thousands  of  TPS's  will  be  developed  to  run  on  the  aany  and  varied  ATE  being 
developed  to  support  hundreds  of  priae  systeas  at  organizational  and  direct 
support  levels  of  maintenance. 

Visits  with  personnel  in  the  following  organizations  have  been  completed: 

(a)  Communication  Electronics  Command 

Headquarters  Staff 

Integrated  Logistics  Support  Division 
Center  for  Tactical  Computer  Systeas 

Product  Manager  -  Test  Measurement  and  Diagnostic  Systems 

(b)  Depot  Systems  Command 

Headquarters  Staff 

(c)  Tobyhanna  Army  Depot 

Automated  Systems  Division 

(d)  RCA  Burlington  MA 

ATE  Staff 

EQUATE  (AN/USM  410) 

STE/ICE  and  derivatives 

(e)  Sacramento  Army  Depot 

(f)  Missile  Comaand  Headquarters 

Visits  are  being  scheduled  at  the  following  organizations: 

(a)  Armament  RAD  Command 

(b)  Armament  Readiness  Command 

(c)  Tank  and  Automotive  Command 

(d)  Central  Test  Measurement  and  Diagnostic  Equipment  Activity 

Additional  details  on  the  ATE  Software  Development  and  Support  Facility 
will  be  provided  in  the  following  documents: 

(a)  ATE  Software  Development  and  Support  Facility 
Functional  Requirements  Document ,  August  1982 

(b)  ATE  Software  Development  and  Support  Facility 
Preliminary  Design  Specification,  October  1982 

(c)  ATE  Software  Development  and  Support  Facility 
Implementation  Plan,  October  1982 


2.0  FACILITY  CONCEPT  DESCRIPTION 

This  section  provides  a  general  description  of  the  ATE  Software 
Development  and  Support  Facility  and  the  products  available  through  the 
library.  Details  will  be  provided  in  the  functional  requirements  document, 
preliminary  design  specification,  and  the  implementation  plan.  The  Facility 
la  structured  to  meet  the  objectives  of  providing  DARCOM  major  subordinate 
commands,  program  managers,  contractors,  and  maintenance  activities  with 
necessary  guides,  hardware  and  software  required  to  develop  and  maintain  high 
quality  TPS  at  a  reduced  coat.  The  key  to  the  Facility's  meeting  the 
objectives  is  that  the  total  contents  of  the  library  must  be  readily  available 
to  all  users  in  a  timely  manner.  Therefore,  the  Facility  must  have  responsive 
communication  links  as  well  as  documents  and  training  courses  to  inform  users 
of  the  content  of  the  library  and  provide  Instructions  on  how  to  use  the 
various  library  products. 
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Ia  many  cases  Che  library  produces  are  not  new  or  unique;  however,  many 
of  them  may  be  used  by  only  one  DARCOM  major  subordinate  command ,  one  program 
office,  one  location,  or  one  contractor.  What  is  new  is  the  concept  of  making 
all  of  the  items  available  Co  all  users.  The  number  and  location  of 
Facilities  will  be  determined  by  a  workload  analysis  at  a  later  date. 

The  following  paragraphs  present  a  general  discussion  of  the 
communication  system,  standard  documentation,  programming  aids  and  tools. 

2.1  Communication  System 


The  communication  system  is  critical  to  the  ATE  Software  Development  and 
Support  Facility.  Through  the  communication  links  all  users  will  be  able  to 
access  the  library  and  use  the  various  products.  A  normal  telephone  with 
telecopiers  will  provide  a  link  for  consulting  on  general  matters  and  will 
provide  timely  instructions  on  accessing  the  library.  Conventional  mail  and 
air  express  shipments  can  be  used  to  handle  large  bulk  transmittals  of  data. 
However,  the  majority  of  communication  will  be  provided  through  a  computer 
hookup  with  the  various  users'  terminals  and  mainframes. 

The  communication  computer  must  have  a  multi-tasking  and  multi- 
programming  operating  system.  It  must  permit  many  simultaneous  users  to 
rapidly  access  the  various  automatic  test  program  generators  (ATPG) , 
translators,  and  data  bases. 

2.2  Standard  Documentation 


The  standard  documentation  required  in  the  Facility  are  many  and  varied; 
in  general  they  will  consist  of  all  the  documents  needed  to  contract  for  and 
to  develop  high  quality,  coat  effective  test  program  sets.  The  current  status 
of  identified  standard  documentation  is  shown  in  appendix  A.  To  improve  the 
dissemination  and  currency  of  the  documents,  many,  if  not  all,  should  be 
available  through  a  data  base  management  system  (DBMS)  as  well  as  hard  copy. 
The  following  provides  a  description  of  the  type  of  standard  documents  chat 
are  required: 

(a)  Facility  Guide  and  Training  Course  -  will  provide  a  description  of 
what  1s  contained  in  the  library  with  instructions  on  how  to  access 
and  use  the  various  items. 

(b)  Test  Program  Set  Acquisition  Guide  -  will  provide  a  "how-to" 
description  of  T?S  acquisition.  The  guide  should  contain  flow 
charts  that  indicate  when  the  tasks  should  be  completed,  who  should 
accomplish  the  Cask,  and  what  supporting  documentation  ia  available. 
The  guide  should  be  structured  to  match  various  acquisition 
scenarios,  such  as  concurrent  with  the  prime  system  contract  award, 
after  prime  system  award,  and  after  the  prime  system  is  fielded. 

(c)  Design  for  Testability  Guide  -  will  provide  design  techniques  for 
use  by  the  weapon  system,  prime  system  and  automatic  test  equipment 
designers  to  make  testing  easier,  thereby  reducing  TPS  complexity 
and  cost. 

d)  Test  Requirement  Document  (TRD)  Standard  -  will  provide  a  standard 

that  specifies  what  type  data  must  be  acquired  for  TPS  development, 
when  it  is  needed,  and  the  format  the  data  must  be  in. 

e)  Model  Unit  Under  Test  (UUT)  Test  Requirements  Document  (TRD) 

Statement  of  Work  (SOW)  -  will  provide  an  on-line  standard  model  SOW 
and  appropriate  contract  data  requirements  list  (CDRL),  as  well  as 
data  item  descriptions  (DID's)  for  incorporation  into  prime  system 
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contracts  to  acquire  the  unit  under  test  (UUT)  TRD  data  as  part  of 
the  prime  system  contract  or  after  the  fact.  The  SOW  will  be 
tailored  for  specific  UUT's  through  queries  and  reference  to 
boilerplate  contained  in  the  data  base. 

(f)  Model  Test  Program  Set  (TPS)  Statement  of  Work  (SOW)  -  will  provide 
an  on-line  standard  model  TPS  SOW  and  DID's  that  can  be  used  to 
contract  for  the  TPS  as  part  of  the  prime  system  contract  or  as  a 
separate  contract.  The  SOW  will  be  tailored  through  queries  and 
reference  to  boilerplate  contained  in  the  data  base. 

(g)  Model  Test  Program  Sec  (TPS)  Specifications  -  will  provide  on-line 
model  system  and  performance  specifications  that  can  be  tailored  to 
define  the  TPS  requirements  through  user  queries. 

(h)  ATLAS  Standard  -  will  provide  copies  of  IEES  Std  7  1  6-1  982  common 
ATLAS  which  is  the  DOD  directed  standard  language  for  preparing  test 
programs . 

(1)  Other  Languages  -  will  provide  copies  of  manuals  covering  languages 
in  widespread  Army  use,  such  as  EQUATE  ATLAS. 

( j )  Test  Program  Set  (TPS)  Configuration  Management  (CM)  Plans  -  will 
provide  an  on-line  model  TPS  CM  plan  that  can  be  easily  tailored  and 
included  in  various  TPS  acquisition  contracts;  Army  depots  that 
will  be  maintaining  the  TPS  may  also  use  a  standard  TPS  CM  plan. 

(k)  Model  TPS  Integrated  Logistic  Support  (ILS)  Plan  -  will  provide  an 
on-line  computer  program  that  through  user  query  and  reference  to 
boilerplate  will  generate  a  tailored  TPS  ILS  plan. 

(l)  Model  TPS  Quality  Assurance  Plan  -  will  provide  an  on-line  computer 
program  Chat  will  generate  a  tailored  TPS  quality  assurance  plan 
through  user  query  and  reference  to  boilerplate. 

(m)  Model  TPS  Request  For  Proposal  (RFP)  -  will  provide  an  on-line 
computer  program  which  embodies  Army  policy  with  respect  to  TPS 
procurement.  A  TPS  Development  RFP  can  be  developed  through  user 
query  and  reference  to  boilerplate. 

(n)  TPS  Style  Guide,  -  will  provide  a  Teat  Program  Style  Guide  outlining 
common  format,  flow  charts,  etc.,  to  aid  in  reducing  the  diverse 
means  of  documenting  TPS.  A  common  style  should  reduce  the  time  and 
coat  to  maintain  future  TPS. 

2.3  Programming  Aida 

Programming  aids  are  defined  as  a  group  of  data  base  systems  that 
provide  information  to  be  used  in  developing  test  program  sets.  Also  included 
are  data  bases  that  are  part  of  a  repairable  management  system.  All  of  the 
data  bases  vlll  be  accessible  through  remote  terminals.  If  required,  special 
access  codes  can  be  used  to  restrict  contractor  use  of  data  bases  that  contain 
proprietary  data  provided  by  other  companies.  The  current  status  of 
identified  programming  aids  is  shown  in  appendix  A. 

The  following  provides  a  description  of  the  type  of  programming  aids 
that  are  required: 

(a)  TPS  Life  Cycle  Cost  (LCC)  Prediction  Model  -  will  provide 
mathematical  models  for  estimating  total  cost  of  developing  and 
maintaining  TPS's  over  the  life  of  a  weapon  or  prime  system. 

(b)  TPS  Development  Cost  Models  -  will  provide  mathematical  models  to 
estimate  cost  of  developing  TPS's  during  the  conceptual  and 
validation  phases  of  weapon  and  prime  system  development. 

(c)  TPS  Schedule  and  Cost  Tracking  System  -  will  provide  a  system  that 
can  easily  track  current  performance  and  cost  against  predicted 
cost.  The  system  will  also  provide  feedback  to  update  the  cost 
prediction  models. 


(d)  Unit  Under  Test  (UUT)  Failure  Data  Collection  System  -  will  provide 
a  computer  aided  system  for  collecting,  organizing  and  storing  data 
on  type  and  frequency  of  UUT  failures.  The  system  should  also  track 
and  provide  an  analysis  of  retest  -  OK  (RTOK)  and  cannot  duplicate 
(CND)  actions.  The  total  analysis  should  be  automatically  completed 
by  grouping  common  classes  of  faults  as  well  as  faults  identified 
against  a  specific  serial  numbered  shop  replacement  unit  (SRU)  or 
line  replacement  unit  (LRU).  The  data  gathering  aspect  of  this  can 
be  automated  as  part  of  the  ATS  operating  system. 

(e)  ATS/TPS  Operations  Oata  Collection  System  -  will  provide  a  computer 
aided  system  for  collecting,  organizing  and  saving  data  about  ATS 
and  TPS  usage,  effectiveness  and  support  cost. 

(f)  TPS  Acquisition  Data  Collection  System  -  will  provide  a  computer 
aided  system  for  collecting,  allocating  and  storing  data  about 
manpower,  material  and  costs  of  TPS  development.  Included  al30  will 
be  Army  cost  for  preparing  request -for-proposals  (RFP's),  conducting 
source  selection,  contract  award  and  contract  monitoring. 

(g)  Library  of  ATLAS  Procedures  -  will  provide  a  library  of  ATLAS 
procedures  to  be  used  in  developing  a  TPS.  The  procedures  will  aid 
in  standardizing  the  resulting  TPS  and  simplifying  the  coding 
process. 

(h)  Unit  Under  Test  (UUT)  versus  Automatic  Test  Equipment  (ATE)  an d 
Interface  Test  Adapter  (ITA)  Matching  Algorithm  -  will  provide  a 
computer  data  base  system  that  will  aid  in  matching  new  UUT  testing 
requirements  with  existing  ATE  and  ITA. 

(i)  Computer  Aided  Design  (CAD)  for  Interface  Test  Adapters  (ITA's)  - 
will  provide  an  on-line  CAD  system  that  will  support  the  design  of 
ITA's. 

(j)  Graphics  Development  Aids  -  will  provide  a  computer  aided  system  to 
assist  in  development  of  software  that  will  provide  a  detailed 
display  of  the  testing  flow  to  the  ATE  operator. 

(k)  TPS  Fault  Isolation  Models  -  will  provide  a  computer  system  to  aid 
in  predicting  the  fault  isolation  potential  for  TPS's  to  be  used  in 
developing  test  specifications. 

(l)  TPS  Quality  Assurance  -  will  provide  computer  quality  assurance 
systems  to  aid  in  developing,  validating  and  verifying  (V&V)  TPS. 
The  models  should  permit  assessment  at  several  different  points  in 
the  development  process.  The  first  assessment  shall  be  conducted 
prior  to  coding  the  test  program, 

(m)  Workload  Analysis  System  -  will  provide  as  part  of  a  repairable 
management  system  an  on-line  data  system  that  consists  of 
classification  and  distribution  profiles  of  repairables  and  matches 
these  profiles  to  the  available  maintenance  assessment  required  to 
test  and  repair  the  failed  UUT. 

(n)  ATE/TPS  Operation  Model  -  will  provide  as  part  of  a  repairable 
management  system  a  model  for  estimating  the  ATE  Software 
Development  and  Support  Facility  workload,  turnaround  time,  etc. 

(o)  Depot  and  General  Support  (GS)  ATE  Shop  Scheduling  System  -  will 
provide  as  part  of  a  repairable  management  system  an  on-line 
computer  program  that  will  accept  user  specified  constraints  and 
thea  provide  a  repair  schedule  that  guarantees  optimum  shop 
throughput . 

(p)  TPS  Developer  Configuration  Status  Accounting  System  (CSAS)  -  will 
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provide  an  on-line  computer  program  and  a  set  of  procedures  that 
will  permit  the  Army  or  contractor  TPS  developer  to  keep  track,  of 
the  UUT,  ATE  and  TPS  conf iguratlon  during  the  TPS  development  phase. 

(q)  Army  TPS  Management  Configuration  Status  Accounting  System  (CSAS)  - 
will  provide  an  on-line  computer  program  and  a  set  of  procedures 
that  will  permit  the  Army  organizations  responsible  for  tracking  and 
maintaining  the  TPS  to  keep  track  of  the  UUT,  ATF.  and  TPS 
con"  juration  after  deployment.  The  Army  TPS  management  CSAS  will 
not  truck  some  of  the  milestones  included  In  the  developer  CSAS  such 
as  *  -.terlm  changes  during  quality  assurance  and  validation  and 
verification  checks;  however.  It  will  contain  additional  information 
such  as  TPS  pnysical  location  and  status  of  engineering  change 
proposals  (ECP's)  that  affect  the  TPS. 

\  r )  Shop  Testing  Capabilities  System  -  will  provide  as  part  of  a 
repairable  management  system  an  on-line  dat >  system  that  will 
display  an  assessment  of  the  shop  testing  capabilities.  The 
assessment  will  Indicate  what  UUT's  can  be  tested  with  the  assigned 
ATE  and  TPS  based  on  the  current  configuration  of  ATE,  TPS  and  UUT. 
It  also  will  provide  an  assessment  based  on  degraded  ATE's  or  ITA's 
capabilities  due  to  failures.  The  data  base  can  be  established  to 
obtain  actoaatlc  updates  from  the  command  configuration  status 
accounting  system. 

(j)  Deficiency  Reporting  and  Feedback  System  -  will  permit  a  rapid 
transmission  of  TPS  deficiencies  to  a  central  organization.  The 
system  should  also  provide  for  a  rapid  feedback  on  workaround 
procedures  and  the  schedule  for  deficiency  correction. 

(t)  Word  Processor  -  provides  a  word  processor  computer  program  for 
preparing  and  updating  the  test  proposal  Instructions  (TPI's'i.  The 
word  processor  will  also  be  available  to  update  the  various  standard 
documentation  Included  within  the  Facility. 

2 . a  Programming  Tools 

Programming  tools  are  defined  as  a  group  of  computer  based  systems  that 
are  used  directly  by  the  programmers  to  develop  test  programs.  There  are  many 
existing  tools  that  perform  similar  functions;  therefore,  one  of  the  major 
tasks  in  this  area  will  be  to  identify  a  specific  tool  or  a  family  of  related 
t o o  1 3  for  Inclusion  in  the  Facility.  The  following  provides  a  description  of 
the  programming  tools  that  are  required: 

(a)  Digital  Automatic  Test  Pattern  Generator  (ATPG)  -  provides  a  family 
of  computer  programs  that  will  analyze  a  digital  circuit  description 
of  a  UUT  and  generate  a  test  program  for  that  UUT. 

(b)  Digital  Simulator  -  provides  a  family  of  computer  programs  that  will 
evaluate  the  fault  detection  effectiveness  of  a  digital  test.  The 
program  should  also  generate  test  responses  and  fault  Isolation 
data . 

(c)  Analog  Automatic  Test  Program  Generator  (ATPG)  -  provides  a  computer 
program  that  will  analyze  an  analog  circuit  description  and  generate 
a  test  program  for  that  UUT. 

(d)  ATLAS  Flowchart  Generator  -  provides  a  computer  program  for 
analyzing  a  test  program  written  in  ATLAS  and  automatically 
generates  a  pictorial  and  commented  flowchart  of  the  program. 

(e)  Text  Editor  -  provides  an  on-line  computer  program  for  viewing  and 
modifying  computer  programs. 

(f)  IEEE  Std  716,  Common  ATLAS  Compiler  and  Syntax  Checker  -  provides  a 
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portable  IEEE  Scd  716  ATLAS  Compiler  that  will  check,  the  syntax  of 
ATLAS  programs,  provide  appropriate  warning  and  error  messages,  and 
translate  the  716  ATLAS  code  into  an  intermediate  code  or  into  a 
format  suitable  for  execution  on  a  specific  test  station. 

(g)  EQUATE  ATLAS  Compiler  and  Syntax  Checker  -  provides  an  EQUATE  ATLAS 
Compiler  that  will  check  the  syntax  of  EQUATE  test  programs,  provide 
appropriate  warning  and  error  messages,  and  translate  the  EQUATE 
ATLAS  into  a  format  suitable  for  execution  on  a  AN/ USM  410. 

(n)  Other  compilers  and  syntax  checkers  -  provide  the  additional 
compilers  and  syntax  checkers  that  are  required  to  support  the 
assigned  TPS. 

(i)  Translators  -  provide  a  family  of  translators  capable  of  translating 
test  programs  written  on  one  tester  to  operate  on  in ;ther  tester  or 
from  one  language  to  another.  For  example,  AN,' USM  .10  ATE  to  GENRAD 
2225  ATE,  Chrysler  DSETS  Language  t'  IEEE  Std  716  Common  ATLAS, 
EQUATE  ATLAS  Language  to  IEEE  Std  716  Common  ATLAS,  IEEE  Std  716 
Common  ATLAS  to  EQUATE  ATLAS  etc. 

(j)  Failure  Modes  Effects  Analysis  (FMEA)  to  ATLAS  Translator  -  provides 
an  on-line  computer  program  that  will  translate  the  FMEA  failure 
signatures  directly  Into  the  diagnostic  portion  of  an  IEEE  Std  716 
Common  ATLAS  test  program. 

(k)  ATLAS  Composing  Terminal  -  provides  an  on-line  computer  program  that 
through  templates  or  some  other  means  lead  a  technician  through  the 
process  of  developing  IEEE  Std  716  ATLAS  test  programs.  The  system 
should  accept  test  requirement  document  (TRD)  data  and  develop  a 
test  program  as  well  as  accept  detailed  source  data  and  generate 
both  a  TRD  and  a  test  program. 

(l)  Self  Learning  TP  Generator  -  provides  a  self  learning  test  program 
generator  using  knowledge  based  system  (KBS)  and  artificial 
intelligence  (AI)  technology.  The  self  learning  generator  will  be 
able  to  automatically  improve  the  test  program  based  on  actual 
testing  data. 

(m)  Test  Program  Development  Stations  -  provide  the  necessary  test 
program  development  stations,  including  EQUATE  ATLAS  and  Common 
ATLAS  Compilers,  to  permit  Initial  development  of  test  programs 
without  using  the  complete  ATE  stations. 

(n)  ATE  Simulator  -  will  be  provided  to  conduct  off-line  testing  for 
logic  and  parameter  errors  during  execution  of  ATLAS  programs. 
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3.Q  RELATIONSHIP  TO  DARCOM  PDSS  CENTERS 


The  major  subordinate  commands  are  each  currently  developing  plans  for 
implementing  the  Post  Deployment  Software  Support  concepts  (PDSS).  Each  of 
the  plans  are  evolving  along  independent  lines.  At  this  time  each  command  is 
planning  to  establish  one  or  more  centers  to  maintain  the  operational 
software.  Several  draft  PDSS  documents  and  major  system  command  messages  were 
reviewed  to  determine  the  relationship  of  the  planned  PDSS  Facilities  to  TPS 
support.  The  various  PDSS  center  plans  ranged  from  specifically  excluding 
TPS’s,  to  including  only  the  AN/USM  410  TPS's,  to  implying  that  all  TPS's  will 
be  controlled/maintained  by  the  respective  PDSS  centers. 

As  stated  previously  in  this  Facility  Concept  Plan,  the  ATE  Software 
Development  and  Support  Facility  will  remain  completely  flexible.  It  will  be 
possible  to  tailor  the  Facility  to  match  the  final  command  decisions  on 
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supporting  TPS  within  or  outside  the  PDSS  centers.  This  Inherent  flexibility 
is  possible  because  the  ATE  Software  Development  and  Support  Facility  is  a 
library  of  test  program  sec  standard  documentation,  programming  aids  and 
tools,  available  for  all  users.  The  actual  TPS  development  and  maintenance 
will  be  conducted  by  other  Army  organizations  or  contractors. 


4.0  CONCLUSION 

(a)  The  proposed  ATS  Software  Development  and  Support  Facility  Concept 
Plan  indicates  that  the  Facility  will  provide  a  viable  opportunity  for  the 
Army  to: 


(1)  have  better  and  more  comprehensive  fault  detection  and  isolation 
thereby  reducing  test  time  and  improving  the  quality  of  the 
diagnosed  unit  under  test  (UUT),  and  increasing  prime  system 
availability. 

(2)  begin  to  control  the  proliferation  of  test  programming  aids  and 
tools,  thus  reducing  acquisition  support  cost. 

(3)  reduce  proliferation  of  complex  interface  test  adapters  tl}at 
must  be  maintained  and  transported  in  the  field. 

(4)  improve  the  quality  of  delivered  test  programs  through  improved 
acquisition  procedures  and  development  aids  and  tools. 

(b)  There  will  be  a  net  reduction  in  the  need  for  skilled  manpower  as  a 
few  centralized  Facilities  will  be  used  rather  than  manning  dozens  of 
duplicative  systems. 

(c)  There  wiLl  be  a  net  reduction  in  cost  as  each  of  the  prime  system 
program  management  offices  will  not  need  to  develop,  buy  or  lease  duplicative 
capabilities. 
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APPENDIX  A 


STATUS  OF  IDENTIFIED  LIBRARY  CONTENTS 


PARAGRAPH  NUMBER  AND  ITEM 


STATUS 

rn  (2) . (3)  no  (Ji 


2.2  STANDARD  DOCUMENTATION 

(a)  Facility  Guide  and  Course 

(b)  Test  Program  Set  Acquisition  Guide  * 

(c)  Design  for  Testability  Guide  * 

(d)  Test  Requirement  Document  (TRD)  Standard  * 

(e)  Model  Unit  Under  Test  TRD  SOW  *  X 

(f)  Model  TPS  SOW  *  X 

(g)  Model  TPS  Specifications  *  x 

(h)  ATLAS  Standard  X 

(i)  Other  Languages  v- 

(J  )  TPS  Configuration  Management  Plan  *  X 

(k)  Model  TPS  ILS  Plan  *  '< 

(l)  Model  TPS  Quality  Assurance  Plan  *  •< 

(m)  Model  TPS  Request  for  Proposal  (RFP)  * 

(n)  TPS  Style  Guide 

2.3  PROGRAMMING  AIDS 

(a)  TPS  Life  Cycle  Cost  Prediction  ModeL  *  ' 

(b)  TPS  Development  Cost  ModeLs  X 

(c)  TPS  Schedule  and  Cost  Tracking  System  * 

(d)  UUT  Failure  Data  Collection  System 

(e)  ATE/TPS  Operations  Data  Collection  System 

(f)  TPS  Acquisition  Data  Collection  System 

(g)  Library  of  Atlas  Procedures 

(h)  UUT  vs  ATE  and  ITA  Matching  .Algorithm 

(I)  CAD  for  ITA  X 

(J )  Graphics  Development  Aids 

(k)  TPS  Fault  Isolation  Models 

(l)  TPS  Quality  Assurance  * 

(m)  Workload  Analysis  System 

(n)  ATE/TPS  Operation  Model 

(o)  Depot  and  GS  ATE  Shop  Scheduling  Svstem  ** 

(p)  TPS  Developer  Configuration  Status  * 

Accounting  System  x 

(q)  Army  TPS  Management  Configuration  * 

Status  Accounting  System  •< 

(r)  Shop  Testing  Capabilities  System 

(s)  Deficiency  Reporting  and  Feedback  System 

(t)  Word  Processor 

(u)  UUT  Failure  Data  Collection  System 
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STATUS  OF  IDENTIFIED  LIBRARY  CONTENT S (Con'd . ) 


PARAGRAPH  NUMBER  AND  ITEM 

(1) 

(2) 

STATUS 

(3)  (4) 

(5) 

2.4  PROGRAMMING  TOOLS 

(a) 

Digital  ATPG 

X 

X 

X 

(b) 

Digital  Simulator 

X 

X 

X 

(c) 

Analog  ATPG 

X 

(d) 

ATLAS  Flowchart  Generator 

X 

X 

(e) 

Text  Editor 

1 

X 

X 

(f  ) 

IEEE  Std  716  Common  ATLAS  Compiler 

and  Syntax  Checker 

X 

X 

X 

(g) 

RCA  EQUATE  ATLAS  Compiler  and 

Syntax  Checker 

X 

(h) 

Other  Compilers  and  Syntax  Checkers 

X 

(i) 

Translators 

X 

(j) 

FMEA  to  ATLAS  Translator 

X 

(k ) 

ATLAS  Composing  Terminal 

X 

X 

(I) 

Self  Learning  Test  Program  Generator 

X 

<  a) 

Test  Program  Development  Stations 

X 

X 

(n) 

ATE  Simulator 

X 

(o) 

EQUATE  TPS  Generation  Station 

X 

LEGEND 

♦Partially  being  Developed 

(D 

EXISTS 

(4) 

REQUIRES 

by  Air  Force  MATE  Program 

CHOICE  OF  ONE 

AS  A  STANDARD 

♦♦Partially  being  Developed 

(2) 

UNDER  DEVELOP¬ 

by  Navy  CSS  Pr jgraa 

MENT 

(3) 

NEEDS  TAILOR¬ 

(5) 

NEEDS 

ING  FOR  ARMY 

DEVELOPMENT 

APPENDIX  B 


RELATED  JOINT  LOGISTICS  COMMANDERS  (JLC)  PANEL 
ON  AUTOMATIC  TESTING 
SUBTASKS 

I.  JLC  PANEL  ON  AUTOMATIC  TESTING  RELATED  MANAGEMENT 
SUBTASKS  (AUG  31) 


II.  JLC  PANEL  ON  AUTOMATIC  TESTING  RELATED  ACQUISITION 
SUPPORT  TASKS  (AUG  31) 


III.  JLC  PANEL  ON  AUTOMATIC  TESTING  RELATED  TESTING 
TECHNOLOGY  SUBTASKS  (AUG  81) 


I.  JLC  PANEL  ON  AUTOMATIC  RELATED  MANAGEMENT  SUBTASKS  (AUG  81) 


OFFICE  OF  PRIMARY 


SUBTASK 

SUBTASK 

RESPONSIBILITY 

MIS  CODE 

TITLE 

(OPR) 

10102 

DOCUMENT  CHANGES 

P.  GROSS/ NMC 

10201 

DATA  ITEM 

DESCRIPTION  LIST 

J.  JOHNSON/ AFLC 

10202 

DATA  ITEM 

DESCRIPTION 

IMPLEMENTATION 

J.  JOHNSON/ AFLC 

10602 

MANAGEMENT  INFOR¬ 

MATION  SYSTEM 

P.  GROSS/ NMC 

II.  JLC  PANEL  ON  AUTOMATIC  TESTING  RELATED  ACQUISITION 
SUPPORT  TASKS  (AUG  81) 


20101 

ISSUE  JOINT  SERVICE 

TERMINOLOGY  STANDARD 

CDR  SANBORN/ NMC 

20201 

JOINT  SERVICE  AT 

INFORMATION  EXCHANGE 

SYSTEM 

J.  DEWEY/ AFLC 

20302 

ELECTRONIC  TESTABILITY 

GUIDE 

E.  WOLANSKI/AFSC 

20303 

NON-ELECTRONIC  TESTABILITY 
GUIDE 

W.  HNATCZUK/ DARCOM 

20304 

TESTABILITY  SPECIFICATION 

E.  WOLANSKI/AFSC 

20305 

TESTABILITY  PROGRAM 

REVIEW 

P.  CROSS/ NMC 

20402 

LCC/ SYSTEMS 

ENGINEERING  MODELS 

MAJ.  FREEMAN/ AF SC 

20501 

TEST  PROGRAM  SET 

DESIGN  HANDBOOK 

D.  CROKE/NMC 

20502 

DIGITAL  ATG 

SELECTION  GUIDE 

P.  GROSS 

20503 

TPS  ACQUISITION  GUIDE 

H.  KIESEL/AFSC 

20504 

TPS  VALIDATION  .AND 

VERIFICATION  GUIDE 

H.  KIESEL/AFSC 

20505 

REVISE  MIL  STD  881 

P.  HOLUB/ DARCOM  OPR 

20506 

ATLAS  SOURCE 

CODE  CONTROL 

D.  CROKE/NMC 

20601 

HARDWARE  INTERFACE 

SPECIFICATION 

D.  BROWN/ AFSC 

20801 

ANALYZE  AND  ISSUE 

TRD  STANDARD 

B.  DALTRY/AFSC 

III.  JLC  PANEL  ON  AUTOMATIC  TESTING  RELATED  TESTING  TECHNOLOGY 
SUBTASKS  (AUG  81) 


OFFICE  OF  PRIMARY 

SUBTASK  SUBTASK  RESPONSIBILITY 

MIS  CODE  TITLE  _ _ (OPR) 


30101  TPS  COST  ESTIMATION 

TECHNIQUES  H  KIESEL/AFSC 

B-2 


30103 


30105 

30107 

30108 

30110 

30111 

30201 

30202 
30508 


TEST  APPLICATIONS 

PROGRAMS 

ATE  SELF  TEST 

SOFTWARE 

ANSI/ IEEE-STD-7 16 , 

BASIC  ATLAS  (DOD 
APPROVED  SUBSET 
OF  ANSI/ ISEE-STD-416 , 
ATLAS) 

DEVELOP  COMMON 
FACILITATING  SOFTWARE 
TEST  PROGRAM  SET 
VERIFICATION,  VALIDATION 
AND  ACCEPTANCE  TOOLS 
BASIC  ATLAS  COMPILER 
DEVELOP  ANALOG  ATPG 
SYSTEM 

DEVELOP  DIGITAL  ATG 
SYSTEM 

SYSTEM  OF  SELF-IMPROVING 
DIAGNOSTICS 


DR.  ALLEN/AFSC 
A.  PUPA/NMC 


G.  KONOMOS/AFSC 

D.  CROKE/NMC 

H.  KIESEL/AFSC 

G.  KONOMQS/ AFSC 

H.  RIESEL/AFSC 
R.  EPSTEIN/NMC 
H.  KIESEL/ A.'SC 
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ABBREVIATIONS 


AI 

ARCOM 

ATS 

ATLAS 

ATPG 

A '.'COM 
CAD 

c; atlas 

CDRL 

CECOM 

CM 

CN’D 

Co  AS 

CSS 

DARCOM 

DBMS 

DESCGM 

DID 

DS 

DSETS 

ECP 

FMEA 

GS 

ID 

1/  ,'vATP 

I LS 

IT  A 

JLC 

KBS 

LCC 

LRU 

MATE 

MICOM 

MIS 

NAVE LEX 

NAVSEA 

NSIA 

OPR 

PDSS 

PM-TMDS 

RFP 

RTOK 

SOW 

SRU 

TMDS 

TOAD 

TP 

TPl 

TPS 

TRA 

TRD 

UUT 

ViV 

VAST 


■Artificial  Intelligence 
Armament  Command 
Automatic  Test  Equipment 

Abbreviated  Te3t  Language  for  All  Systems 
Automatic  Test  Pattern  Generator 
Aviation  Command 
Computer  Aided  Design 

Common  Abbreviated  Test  Language  for  All  Systems 
Contract  Data  Requirements  List 
Communications  Electronics  Command 
Configuration  Management 
Cannot  Duplicate 

Configuration  Status  Accounting  System 
Consolidated  Support  System 
Development  and  Readiness  Command 
Data  Base  Management  System 
Depot  System  Command 
Data  Item  Description 
Direct  Support 

Direct  Support  Electrical  Test  Set 
Engineering  Change  Proposal 
Failure  Modes  Effects  Analysis 
General  Support 
Interface  Device 

Industry/ Joint  Services  Automatic  Testing  Project 

Integrated  Logistic  Support 

Interface  Test  Adapter 

Joint  Logistic  Commanders 

Knowledge  Based  System 

Life  Cycle  Cost 

Line  Replacement  Unit 

Modular  Automatic  Test  Equipment 

Missile  Command 

Management  Information  System 

Naval  Electronics  System  Command 

Naval  Sea  System  Command 
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20.  ABSTRACT  (Continued) 

Users  of  the  Facility  will  find  the  library  functions  as  a: 

a.  focal  point  for  information  on  TPS  acquisition  and 
development  problems, 

b.  means  to  predict  the  cost  for  TPS  development  and 
then  track  the  actual  cost  during  the  life  cycle  of 
the  TPS, 

c.  source  of  guidance  on  preparation  of  TPS  documents, 

d.  means  to  consolidate  and  transmit  users'  problems, 

e.  suooort  facility  to  aid  in  matching  shop  test  assets 
to  UUT's  and  spare  parts. 

In  order  to  support  TPS  development  and  maintenance  agencies' 
requirements  the  above  functions  must  be  performed.  To  complete  the 
required  functions  the  Facility  (library)  must  provide  configuration  status 
accounting  system  capabilities,  automatic  test  program  generators  (ATPG's) 
and  simulators,  a  family  of  ATLAS  compilers,  composing  terminals, 
programming  stations,  plus  other  programming  aids,  programming  tools  and 
standard  acquisition  and  support  documentation. 

With  all  facets  of  the  Facility  in  place,  it  will  then  be  capable  of  making 
the  most  efficient  use  of  limited  manpower  resources  while  continuing  to 
function  within  the  current  or  future  organization  structure  of  DARCOM  major 
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1  .0  INTRODUCTION 

The  US  Army  proposed  Software  Development  and  SuDport  Facility  will 
serve  as  a  library  for  many  organizations,  government  and  contractor,  that 
are  engaged  in  specifying,  developing  and  maintaining  test  program  sets.  At 
this  time  the  Facility  concept  does  not  include  support  of  the  automatic  test 
equipment  (ATE)  operating  system  software;  however,  it  can  be  expanded  to 
include  new  support  philosophies.  Throughout  this  document  the  term  test 
program  set  (TPS)  will  mean:  a)  the  applications  software  or  test  program 
(TP)  required  to  test  a  specific  unit  under  test  (UUT),  b)  the  interface  test 
adapter  (IT A)  or  interface  device  (ID)  that  is  required  to  mechanically  and 
electrically  connect  the  automatic  test  equipment  (ATE)  to  the  specific  UUT, 
c)  the  test  program  instruction  (TPI)  which  is  the  documentation  needed  to 
operate  and  maintain  the  TP  and  ITA.  The  Facility  will  contain  all  standard 
documentation,  programming  aids  and  tools  necessary  to  develop  and  maintain 
consistently  high  quality  TPS  at  a  reduced  life  cycle  cost  (LCC).  Through 
the  use  of  computer  communication  links,  telephone,  and  mail,  the  Facility  will 
make  available  the  contents  of  the  library  to  many  users.  Many  different 
Army  and  contractor  organizations  will  require  access  to  the  Facility.  The 
different  agencies  include  those  that: 

(a)  conduct  TPS  dcquisition  planning 

(b)  conduct  TPS  acquisition 

(c)  conduct  TPS  development 

(d)  conduct  independent  TPS  validation  and  verification  (V&V) 

(e)  control  and  maintain  the  TPS  after  deployment 
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The  proposed  concept  for  an  ATE  software  development  and  support 
facility  is  being  developed  with  organizational  flexibility  as  a  keystone.  The 
Facility  can  function  within  the  current  or  future  organization  structure  of 
various  DARCOM  major  subordinate  commands.  Management  plans  such  as  the 
Army  Post  Deployment  Software  Support  (PDSS)  °1ans  and  the  Army  Test 
Program  Set  (TPS)  Management  Plan  were  also  considered  during  the 
development  of  this  concept. 

Additional  details  on  the  need  for  the  Facility  and  the  concept  evolution 
are  contained  in  the  "US  Army  proposed  ATE  Software  Development  and 
Support  Facility  Concept  Plan"  of  28  April  1982. 

1 . 1  Functional  Requirements  Document  Objectives 

This  document  specifies  the  functional  requirements  that  the  Facility 
must  satisfy.  The  functional  requirements  document  also  provides  a  basis  for 
the  mutual  understanding  between  the  designers  and  users  of  the  Facility. 

1 .2  Facility  Concept  Summary 

Currently  the  Army  is  experiencing  an  explosive  growth  in  the 
acquisition  of  complex  electronic  systems.  The  fielding  of  the  complex 
systems  in  the  face  of  a  reduced  manpower  pool  and  reduced  technical 
training,  thus  lower  skill  levels,  is  accelerating  the  requirement  for  automatic 
testing  at  all  levels  of  maintenance.  A  1980  Industry  /  Joint  Services  Automatic 
Testing  Project  study  indicated  that  the  US  Army  was  spending  approximately 
$800,000,000.00  annually  on  automatic  testing.  Over  50%  of  this  figure  is  for 
development  of  the  software  included  in  the  test  program  sets. 
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The  proposed  ATE  Software  Development  and  Support  Facilities  will 
provide  a  library  of  standard  documentation,  test  programming  aids  and  tools 
that  will  help  to  develop  higher  quality  test  program  sets  (TPS)  at  a  reduced 
life  cycle  cost  (LCC).  The  content  of  the  libraries  will  be  available  to  all 
users  through  various  communication  links;  therefore,  it  will  not  be  necessary 
for  all  users  to  procure  duplicative  aids  and  tools.  The  users  of  the  library 
cover  a  broad  spectrum  of  personnel  ranging  from  Development  and  Readiness 
Command  Headquarters  Staff,  major  subordinate  command  headquarters  staff 
and  management  offices,  prime  system  program  management  offices,  prime 
system  and  TPS  contractors,  to  depots. 

Due  to  the  flexibility  inherent  in  the  Facility  it  can  be  tailored  to  fit  into 
the  Army  Post  Deployment  Software  Support  Center  concepts  and  the  Army 
TPS  Management  Plan  as  they  evolve.  The  number  and  location  of  Facilities 
are  also  flexible  and  can  be  determined  by  a  detailed  work  load  analysis. 

(a)  The  proposed  ATE  Software  Development  and  Support  Facility 
Concept  Plan  indicates  that  the  Facility  will  provide  a  viable 
opportunity  for  the  Army  to: 

(1)  obtain  better  and  more  comprehensive  fault  detection  and 
isolation,  thus  improving  the  quality  of  the  diagnosed  unit  under 
test  (UUT)  and  increasing  prime  system  availability. 

(2)  begin  to  control  the  proliferation  of  test  programming  aids  and 
tools,  thus  reducing  acquisition  support  costs. 

(3)  reduce  proliferation  of  complex  interface  test  adapters  that  must 
be  maintained  and  transported  in  the  field. 
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(4)  improve  the  quality  of  delivered  test  programs  through  improved 
acquisition  procedures  and  development  aids  and  tools. 

(b )  There  will  be  a  net  reduction  in  skilled  manpower  as  a  fe.v 
centralized  Facilities  will  be  used  rather  than  manning  dozens  of 
duplicative  systems. 

(c)  There  will  be  a  net  reduction  in  cost  as  each  of  the  prime  system 

program  management  offices  will  not  need  to  develop,  buy,  or  lease 
duplicative  capabilities. 

Additional  details  on  the  Facility  are  contained  in  the  U.  S.  Army 
proposed  ATE  Software  Development  and  Support  Facility  Concept 
Plan,  Implementation  Plan,  and  Preliminary  Design  Specification. 
The  Facility  Concept  Description,  paragraph  2.0  of  the  Concept  Plan 
is  included  in  this  document  as  Appendix  C. 


2.0  FACILITY  FUNCTIONAL  REQUIREMENTS 


The  functions  of  the  ATE  Software  Development  and  Support  Facility  are 
varied  and  will  require  a  broad  range  of  standard  documentation, 
programming  aids  and  programming  tools  to  meet  the  requ irements .  The 
functions  fall  within  three  major  categories;  however,  there  are  some 
overlapping  functions.  The  first  category  contains  functions  that  the 
acquisition  agency  must  do  to  plan,  budget,  contract,  monitor  and  accept  test 
program  sets.  For  purposes  of  this  report  the  acquisition  agency  is  defined 
as  the  program  management  office,  depot  or  contractor  that  will  contract  for 
the  TPS  development.  The  second  category  contains  functions  that  the  test 
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program  set  developers  and  maintainers  must  perform  to  prepare,  verify, 
validate,  update,  repair,  and  track  the  configuration  and  location  of  the 
TPS's.  The  TPS  maintainers  are  defined  as  the  various  Army  organic  deoots 
as  .veil  as  the  contractor  operated  facilities  that  will  update  and  maintain  the 
test  program  sets.  The  third  category  contains  functions  that  the  prime 
system  maintenance  shops  must  perform  when  they  use  the  ATE  and  TPS  to 
fault  diagnose,  fault  isolate  and  repair  the  units  under  test. 

The  preceding  categories  are  useful  to  group  the  various  functions; 
however,  the  Army  organizations  that  actually  complete  the  functions  are 
varied.  For  example,  in  one  case  the  prime  weapon  system  program 
management  office  will  complete  the  category  one  functions,  the  prime 
contractor  will  complete  the  category  two  TPS  development  functions,  a 
contractor  depot  will  complete  the  category  two  TPS  maintence  functions,  and 
the  Army  general  support  level  maintenance  shop  will  complete  the  category 
three  functions.  In  another  case  an  Army  depot  will  complete  the  functions 
in  all  three  categories. 

Appendix  A  provides  a  detailed  matrix  that  cross  references  the  contents 
of  the  Facility  as  specified  in  the  Concept  Plan  with  the  Facility  functions 
that  are  described  in  the  following  subparagraphs. 

2 . 1  Functions  Required  To  Support  TPS  Acquisition  Agencies 

Acquisition  agencies  are  defined  as  the  program  management  office,  depot 
or  contractor  that  accomplish  the  following  functions  to  enable  them  to  plan, 
budget,  contract  for,  monitor  and  accept  test  program  sets: 

1.  act  as  focal  point  for  test  program  set  acquisition  problems 

2.  provide  means  to  predict  and  track  cost  for  test  program  set  (TPS) 
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development 

3.  provide  guidance  on  preparation  of  test  program  set  acquisition 
documents 

4.  provide  a  means  to  consolidate  test  proqram  set  users'  problems  for 
transmission  to  develocinent  agencies 

5.  provide  Configuration  Status  Accounting  System  (CSAS)  capabilities 

2.1.1  Act  As  Focal  Point  For  Test  Program  Set  Acquisition  Problems 

To  be  responsive  to  Army  needs  the  library  must  be  able  to  respond  to 
new  and  ever-changing  requ  irements .  To  accomplish  this  purpose,  the 
Facility  must  have  the  means  to  collect  information  on  TPS  acquisition 
problems  as  well  as  development  problems.  The  Facility  should  then  provide 
concise  information  on  TPS  standards,  aids  and  tools  requirements  to  the 
appropriate  development  agency.  The  development  agency  will  then  procure 
the  necessary  items  to  permit  solving  the  myriad  of  problems.  Through  this 
process  the  Facility  will  always  contain  the  latest  technology  to  aid  in 
reducing  the  cost  and  time  to  develop  and  maintain  high  quality  TPS. 

The  Facility  must  be  able  to  plan  and  schedule  the  use  of  all  the  items 
contained  in  it  so  each  user  will  have  access  when  required. 

The  Facility  must  also  have  the  capability  to  identify  and  contact  various 
experts  throughout  the  Army  who  can  provide  advice  on  solving  new  and 
unique  problems  related  to  TPS's. 

To  assure  the  optimum  use  of  the  various  library  contents,  the  Facility 
must  be  capable  of  providing  training  on  the  use  of  the  various  standards, 
aids  and  tools  provided. 
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2.1.2  Provide  '/leans  To  Predict  And  Track  Cost  For  TPS  Development 

One  critical  function  that  the  Facility  must  satisfy  is  to  provide  a  means 
to  predict  the  cost  for  TPS  development  and  then  track  the  actual  cost  during 
the  life  cycle  of  TPS.  One  of  the  most  critical  problems  facing  each  new 
prime  system  program  manager  is  to  accurately  budget  the  required  funds  and 
appropriate  cash  flow  to  permit  meeting  overall  performance  and  schedule 
requirements.  As  the  TPS  will  require  the  majority  of  the  support  dollars,  it 
is  imperative  that  TPS  cost  prediction  models  based  on  historical  experience 
be  made  available.  After  the  TPS  development  has  begun,  it  is  also 
imperative  that  the  program  management  office  be  able  to  identify  the  actual 
cost  for  the  various  hardware,  software  and  documentation  that  comprise  the 
TPS.  The  accumulated  cost  data  should  also  feed  back  to  the  cost  prediction 
models  to  provide  an  update  for  future  prime  system  program  managers. 

2.1.3  Provide  Guidance  On  Preparation  Of  TPS  Acquisition  Documents 
During  the  initial  formation  of  prime  system  program  management  offices 

and  drafting  of  the  various  acquisition  documents,  the  availability  of  qualified 
personnel  is  normally  very  limited.  Therefore,  to  help  alleviate  this  problem, 
the  Facility  should  provide  various  data  bases,  guides  and  model  documents 
based  on  successful  programs  to  augment  the  limited  personnel.  The  various 
documents  and  data  bases  must  be  easily  accessible  to  the  users  and  must 
permit  tailoring  to  the  unique  requirements  of  the  programs. 

2.1.4  Provide  A  Means  To  Consolidate  TPS  Users'  Problems  For  Transmission 
To  Development  Agencies 

The  Facility  must  provide  a  means  to  easily  obtain  user  data  on  the 
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effectiveness  of  the  TPS  in  field  use.  It  also  must  provide  the  means  to 
assure  that  all  cf  the  identified  deficiencies  are  properly  categorized  with 
appropriate  priorities  and  relayed  to  the  proper  maintenance  or  acquisition 
agency  for  resolution. 

2.1.5  Provide  Configuration  Status  Accounting  System  (CSAS)  Capabilities 

The  Facility  must  provide  the  various  data  bases  that  will  enable  the 
TPS  development  and  maintenance  agencies  to  complete  their  configuration 
status  accounting  functions.  The  diverse  nature  of  test  program  sets 
containing  hardware,  software  and  documentation  coupled  with  the  large 
number  of  TPS's  entering  the  Army  inventory  requires  a  responsive  CSAS 
that  can  be  readily  tailored  to  each  user's  needs.  The  CSAS  also  should 
provide  appropriate  acquisition  agencies  with  the  capability  to  trace  the 
engineering  change  proposal  and  modification  status  of  selected  TPS's. 

Effective  management  of  development,  duplication,  distribution,  and 
post-deployment  support  of  TPS's  requires  careful  definition  of  all  baseline 
components;  changes  to  those  components  also  need  to  be  defined  since  these 
changes  together  with  the  baselines  specify  the  TPS  evolution.  This  process, 
known  as  Configuration  Identification,  is  an  essential  input  to  the 
Configuration  Status  Accounting  (CSA)  effort.  CSA  is  a  mechanism  for 
maintaining  a  record  of  how  the  TPS  or  ATE  has  evolved  and  where  the  item 
is  at  any  time  relative  to  what  appears  in  the  published  baseline 
documentation.  ATE  and  TPS  CSA  is  the  administrative  tracking  and 
reporting  of  all  items  formally  identified  and  controlled.  It  also  involves  the 
maintenance  of  records  to  support  the  ATE/TPS  configuration  auditing 
process.  ATE/TPS  CSA  requires  inputs  from  all  the  functions  of 
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across  this  spectrum,  several  ATPG's  and  simulators  will  be  required  to 
support  the  Facility  users. 

Selecting  and  standardizing  certain  test  program  generating  aids  is 
essential  to  successful  TPS  development  and  post-deployment  support  efforts. 
The  most  efficient  and  effective  approach  to  validation  and  verification  (V&V) 
of  TPS  requires  complete  knowledge  of  the  test  program  design 
strategy /methodology .  With  this  information,  the  V&V  process  can  take 
advantage  of  the  same  intelligence  used  to  develop  the  test  program,  thereby 
significantly  reducing  the  learning  curve  and  recurring  engineering  costs 
associated  with  the  V&V  process.  Training  courses  will  also  be  provided  to 
the  users  of  these  software  tools. 

2.2.2  Provide  A  Family  Of  ATLAS  Compilers  and  Translators 

The  Facility  should  provide  a  series  of  compilers  and  syntax  checkers 
designed  to  operate  on  the  ATE  and  programming  stations  that  are  projected 
for  widespread  Army  use.  As  a  minimum  the  library  must  contain  a  compiler 
written  in  RCA  EQUATE  ATLAS  to  operate  on  the  USM  410  and  a  rehostable 
compiler  written  in  IEEE  Std  716  Common  ATLAS  (the  currently  approved  DOD 
language  for  preparing  test  programs).  The  rehostable  compiler  should 
operate  on  the  AN/USM  410  and  the  Direct  Support/ Automatic  Test  Support 
System  (DS/ATSS)  as  well  as  other  organizational  and  direct  support  ATE 
that  are  under  current  or  planned  development.  The  library  should  also 
provide  access  to  compilers  written  in  peculiar  languages  that  are  being 
acquired  through  existing  major  weapon  system  contracts.  For  example,  the 
M-1  tank  is  acquiring  the  AN/USM  410,  STE/XM-1,  Thermal  System  Test  Set 
(TSTS),  Direct  Support  Electrical  System  Test  Set  (DSESTS),  etc.  ATE  to 
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support  the  tank  at  various  maintenance  levels.  Each  of  these  pieces  of  ATE 
have  different  compilers  written  in  different  languages  that  will  be  used  to 
develop  and  maintain  a  large  number  of  test  programs. 

To  save  the  investment  in  existing  TPS's,  the  Facility  should  provide 
translators  that  can  translate  test  programs  prepared  for  one  set  of  hardware 
(ATE)  to  enable  operation  on  a  different  station.  For  example,  the  Army  may 
find  it  cost  effective  to  translate  programs  designed  to  operate  on  the 
USM-410  ATE  into  programs  which  will  operate  on  the  DS'ATSS  ATE  or  the 
AN/USM-465. 

2.2.3  Provide  A  Family  Of  ATLAS  Composing  Terminals  and  Programming 
Stations 

The  Facility  should  provide  a  series  of  composing  terminals  and 
programming  stations  to  aid  in  the  development  of  test  programs,  ^reparation 
of  efficient  test  programs  requires  extensive  use  of  skilled  manpower; 
therefore,  the  library  should  provide  composing  terminals  to  reduce  the  time 
and  skills  required  to  prepare  test  programs.  The  composing  terminals 
should  be  capable  of  preparing  test  programs  in  IEEE  Std  716  Common  ATLAS 
(C/ATLAS)  and  RCA  EQUATE  ATLAS  plus  other  languages  that  are  in 
widespread  Army  use  on  major  prime  systems. 

Much  of  the  initial  test  program  development  and  debugging  may  be 
accomplished  through  the  use  of  programming  stations  in  lieu  of  the  actual 
ATE.  To  reduce  the  cost  of  hardware  committed  to  test  programs,  the 
Facility  should  provide  a  family  of  programming  stations  to  conduct  the  initial 
programming  and  debug  efforts.  The  final  verification  and  validation  will  be 
conducted  on  the  actual  ATE,  thus  the  number  of  ATE  stations  committed  to 
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2.3.1  Provide  TPS  Shop  Management  Aids 

The  Facility  must  be  able  to  support  functions  that  aid  in  matching 
maintenance  shop  testing  assets  (ATE,  TPS  and  technician)  to  UUT's  and 
available  spare  parts.  It  also  should  aid  in  the  function  of  scheduling 
various  general  support  and  depot  maintenance  shops  to  improve  shop 
productivity  and  input,  thus  increasing  the  number  of  useable  spares 
available  for  operational  use. 


3.0  COMMUNICATION  SYSTEM 


The  key  to  the  success  of  the  library's  meeting  all  the  various  functional 
requirements  is  to  assure  that  all  of  the  documents,  aids  and  tools  are  readily 
available  to  the  potential  users.  Therefore,  all  the  data  bases,  ATPG's, 
simulators,  etc.  should  be  available  to  government  and  contractor  users 
through  a  real  time  computerized  communication  net.  Appropriate  passwords 
and  control  procedures  must  be  established  to  assure  that  only  authorized  and 
trained  agencies  and  personnel  may  access  the  system. 


13 


5  SEPTEMBER  1982 


APPENDIX  A 

ATE  SOFTWARE  DEVELOPMENT  AND  SUPPORT  FACILITY  (LIBRARY) 
FUNCTIONS  VERSUS  CONTENTS 


Functions  and  FRD  paragraph  numbers 

2.1  Support  TPS  acquisition  agencies 

2.1.1  act  as  focal  point  for  TPS 
TPS  acquisition  problems 


2.1.2  provide  means  to  predict  and 

track  cost  for  TPS  development 


2.1.3  provide  guidance  on  preparation 
of  TPS  acquisition  documents 


Library  contents  and  concept  plan 
(see  App.  C)  paragraph  number 

2.2  (a)  Facility  Guide  and 
Course 

2.3  (f)  TPS  Acquisition  Data 
Collection  System 

2.3  (m)  ATE/TPS  operation  model 


2.3  (a)  TPS  Life  Cycle  Cost 
Prediction  Model 

2.3  (b)  TPS  Development  Cost 
Models 

2.3  (c)  TPS  Schedule  and  Cost 
Tracking  System 


2.2  (b)  TPS  Acquisition  Guide 

2.2  (c)  Design  for  Testability 
Guide 

2.2  (d)  Test  Requirement  Document 
(TRD)  Standard 

2.2  (e)  -Model  Unit  Under  Test 
TRD  SOW 

2.2  (f)  Model  TPS  SOW 

2.2  (g)  Model  TPS  Specifications 

2.2  (h)  IEEE  ATLAS  Standards 

2.2  (i)  Other  Languages 

2.2  (j)  TPS  Configuration 
Management  Plan 

2.2  (k)  Model  TPS  ILS  Plan 
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Functions  and  FRO  paragraph  numbers 


2.1.4  provide  a  means  to  consolidate 
TPS  users'  problems  for 
transmission  to  development 
agencies 


2.1.5  provide  Configuration  Status 
Accounting  System  (CSAS) 
capabilities 


2.2  Support  TPS  development  and 
maintenance  agencies 

2.2.1  provide  a  family  of  automatic 
test  program  generators  and 
simulators 


2.2.2  provide  a  family  of  ATLAS 
compilers  and  translators 


Library  contents  and  concept  plan 
(see  App.  Cj  paragraph  number 

2.2  (I)  'lode!  TPS  Quality 
Assurance  Plan 

2.2  (m)  ‘Vodel  TPS  Request  for 

Droposal  (RFP) 

2.3  (h)  UUT  vs.  ATE  and  ITA 

matching  algorithm 

2.3  (t)  Word  Processor 

2.3  (m)  Workload  Analysis  System 

2.3  (d)  UUT  Failure  Data 
Collection  System 

2.3  (e)  ATE/TPS  Ooerations 

Data  Collection  System 

2.3  (s)  Deficiency  Reporting 
and  Feedback  System 


2.3  (p)  TPS  Developer  Confiqura- 
tion  Status  Accounting 
System 

2.3  (q)  Army  TPS  Management  CSAS 


2.4  (a)  Digital  ATPG 
2.4  (b)  Digital  Simulator 
2.4  (c)  Analog  ATPG 


2.4  (f)  IEEE  Std  716  C.  ATLAS 
Compiler  and  Syntax 
Checker 

2.4  (g)  RCA  EQUATE  ATLAS 
Compiler  and  Syntax 
Checker 
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Functions  and  FRD  paragraph  number 


2.2.3  provide  a  family  of  ATLAS 
composing  terminals  and 
programming  stations 


2.2.4  provide  a  family  of  programming 
aids  and  tools 


2.3  Support  GS  and  depot 
maintenance  shops 

2.3.1  provide  TPS  shop 
management  aids 


Library 

contents  and  concept  plan 

( see 

App.  C)  paragraph  number 

2.4 

(h) 

Other  Compilers  and 
Syntax  Checkers 

2.4 

(i) 

T  ransl  ators 

2.4 

(j) 

F'<EA  to  ATLAS 

T  ransl ator 

2.4 

no 

ATLAS  Composing  Termina 

2.4 

(i) 

Self  Learning  Test 

Program  Generator 

2.4 

(m ) 

Test  Program  Development 

Stations 


2.2 

(n) 

TPS  Style  Guide 

2.3 

(g) 

Library  of  ATLAS 
Procedures 

2.3 

(i) 

CAD  for  ITA 

2.3 

(j) 

Graphics  Development  Aids 

2.3 

(k) 

TPS  Fault  Isolation 
'todels 

2.3 

(l) 

TPS  Quality  Assurance 

Tools 

2.4 

(d) 

ATLAS  Flowchart  Generator 

2.4 

(e) 

Text  Editor 

2.4 

(n) 

ATE  Simulator 

2.3 

(m) 

ATE/TPS  Operation  'todel 

2.3 

(o) 

Depot  and  CS  ATE  Shop 
Scheduling  System 

2.3 

(r) 

Shop  Testing  Capabilities 

System 
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A! 


A 'LAS 
V  '  J  G 

AVCOM 

CAD 

C  ATLAS 

CDRL 

CECOM 

CM 

CND 

CSA 

CS  AS 

CSS 

DARCOM 

DBMS 

DESCOM 

DID 

OS 

DS/ATSS 

DSETS 

ECP 


Artificial  Intelligence 
Arnanent  Command 
Automatic  Test  Equipment 
Abbreviated  Test  Language  for  All  Systems 
Automatic  Test  Program  (or  pattern)  Generator 
Aviation  Command 
Computer  Aided  Design 

Common  Abbreviated  Test  Language  for  Ail  Systems 
Contract  Data  Requirements  List 
Communications  Electronics  Command 
Configuration  Management 
Cannot  Duplicate 
Configuration  Status  Accounting 
Configuration  Status  Accounting  System 
Consolidated  Support  System 
Development  and  Readiness  Command 
Data  Base  Management  System 
Depot  System  Command 
Data  Item  Description 
Direct  Support 

Direct  Support/ Automatic  Test  Support  System 
Direct  Support  Electrical  Test  Set 
Engineering  Change  Proposal 
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FMEA 

Failure  Modes  Effects  Analysis 

GS 

General  Support 

ID 

Interface  Oevice 

l/JSATP 

Industry  '  Joint  Services  Automatic  Testing  Project 

ILS 

Integrated  Logistic  Support 

ITA 

Interface  Test  Adapter 

JLC 

Joint  Logistic  Commanders 

K3S 

Knowledge  Based  System 

LCC 

Life  Cycle  Cost 

LRU 

Line  Replacement  Unit 

MATE 

Modular  Automatic  Test  Equipment 

Ml  COM 

Missile  Command 

MIS 

Management  Information  System 

NAVELEX 

Naval  Electronics  System  Command 

NAVSEA 

Naval  Sea  System  Command 

NSI A 

National  Security  Industrial  Association 

OPR 

Office  of  Primary  Responsibility 

POSS 

Post  Deployment  Software  Support 

PM-TMOS 

Product  Manager-Test  Measurement  and  Diagnostic  Systems 

RFP 

Request  for  Proposal 

RTOK 

Retest  -  OK 
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SOW 

Statement  of  Work 

SR'J 

Shop  Replacement  Unit 

T  MO  S 

Test  Measurement  and  Diagnostic 

TOAD 

Tobyhanna  Army  Depot 

TP 

Test  Program 

TPI 

Test  Program  Instruction 

TPS 

Test  Program  Set 

TRA 

Test  Requirements  Analysis 

TRO 

Test  Requirements  Document 

TSTS 

Thermal  System  Test  Set 

UUT 

Unit  Under  Test 

vsv 

Validation  and  Verification 

VAST 

Versatile  Automated  Shoo  Tester 
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APPENDIX  C 

FACILITY  CONCEPT  DESCRIPTION  EXCERPT  FROM  THE 
ATE  SOFTWARE  DEVELOPMENT  AND  SUPPORT  FACILITY 

CONCEPT  PLAN 

2.0  FACILITY  CONCEPT  DESCRIPTION 

This  section  provides  a  general  description  of  the  ATE  Software 
Development  and  Support  Facility  and  the  products  available  through  the 
library.  Details  will  be  provided  in  the  functional  requirements  document, 
preliminary  design  specification,  and  the  implementation  plan.  The  Facility  is 
structured  to  meet  the  objectives  of  providing  DARCOM  major  subordinate 
commands,  program  managers,  contractors,  and  maintenance  activities  with 
necessary  guides,  hardware  and  software  required  to  develop  and  maintain 
high  quality  TPS  at  a  reduced  cost.  The  key  to  the  Facility's  meeting  the 
objectives  is  that  the  total  contents  of  the  library  must  be  readily  available  to 
all  users  in  a  timely  manner.  Therefore,  the  Facility  must  have  responsive 
communication  links  as  well  as  documents  and  training  courses  to  inform  users 
of  the  content  of  the  library  and  provide  instructions  on  how  to  use  the 
various  library  products. 

In  many  cases  the  library  products  are  not  new  or  unique;  however, 
many  of  them  are  used  by  only  one  DARCOM  major  subordinate  command,  one 
program  office,  one  location,  or  one  contractor.  What  is  new  is  the  concept 
of  making  all  of  the  items  available  to  all  users.  The  number  and  location  of 
Facilities  will  be  determined  by  a  workload  analysis  at  a  later  date. 

The  following  paragraphs  present  a  general  discussion  of  the 
communication  system,  standard  documentation,  programming  aids  and  tools. 
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2.1  COMMUNICATION  SYSTEM 

The  communication  system  is  critical  to  the  ATE  Software  Development 
and  Support  Facility.  Through  the  communication  links  all  users  will  be  able 
to  access  the  library  and  use  the  various  products. 

A  normal  telephone  with  telecopiers  will  provide  a  link  for  consulting  on 
general  matters  and  will  provide  timely  instructions  on  accessing  the  library. 
Conventional  mail  and  air  express  shipments  can  be  used  to  handle  large  bulk 
transmittals  of  data.  However,  the  majority  of  communication  will  be  provided 
through  a  computer  hookup  with  the  various  users'  terminals  and  mainframes. 

The  communication  computer  must  have  a  multi-tasking  and  multi- 
programming  operating  system.  It  must  permit  many  simultaneous  users  to 
rapidly  access  the  various  automatic  test  program  generators  (ATPG), 
translators,  and  data  bases. 

2.2  STANDARD  DOCUMENTATION 

The  standard  documentation  required  in  the  Facility  are  many  and 
varied;  in  general  they  will  consist  of  all  the  documents  needed  to  contract 
for  and  to  develop  high  quality,  cost  effective  test  program  sets.  The 
current  status  of  identified  standard  documentation  is  shown  in  appendix  A. 
To  improve  the  dissemination  and  currency  of  the  documents,  many,  if  not 
all,  should  be  available  through  a  data  base  management  system  (DBMS)  as 
well  as  hard  copy.  The  following  provides  a  description  of  the  type  of 
standard  documents  that  are  required: 

(a)  Facility  Guide  and  Training  Course  -  will  provide  a  description  of 
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2.1  COMMUNICATION  SYSTEM 

The  communication  system  is  critical  to  the  ATE  Software  Development 
and  Support  Facility.  Throuqh  the  communication  links  all  users  will  be  able 
to  access  the  library  and  use  the  various  products. 

A  normal  telephone  with  telecopiers  will  provide  a  link  for  consulting  on 
general  matters  and  will  provide  timely  instructions  on  accessing  the  library. 
Conventional  mail  and  air  express  shipments  can  be  used  to  handle  large  bulk 
transmittals  of  data.  However,  the  majority  of  communication  will  be  provided 
through  a  computer  hookup  with  the  various  users'  terminals  and  mainframes. 

The  communication  computer  must  have  a  multi-tasking  and  multi- 
programming  operating  system.  It  must  permit  many  simultaneous  users  to 
rapidly  access  the  various  automatic  test  program  generators  (ATPG), 
translators,  and  data  bases. 

2.2  STANDARD  DOCUMENTATION 

The  standard  documentation  required  in  the  Facility  are  many  3  n  d 
varied;  in  general  they  will  consist  of  all  the  documents  needed  to  contract 
for  and  to  develop  high  quality,  cost  effective  test  program  sets.  The 
current  status  of  identified  standard  documentation  is  shown  in  appendix  A. 
To  improve  the  dissemination  and  currency  of  the  documents,  many,  if  not 
all,  should  be  available  through  a  data  base  management  system  (DBMS)  as 
well  as  hard  copy.  The  following  provides  a  description  of  the  type  of 
standard  documents  that  are  required: 

(a)  Facility  Guide  and  Training  Course  -  will  provide  a  description  of 
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2.1  COMMUNICATION  SYSTEM 

The  communication  system  is  critical  to  the  ATE  Software  Development 
and  Support  Facility.  Through  the  communication  links  all  users  will  be  able 
to  access  the  library  and  use  the  various  products. 

A  normal  telephone  with  telecopiers  will  provide  a  link  for  consulting  on 
general  matters  and  will  provide  timely  instructions  on  accessing  the  library. 
Conventional  mail  and  air  express  shipments  can  be  used  to  handle  iarge  bulk 
transmittals  of  data.  However,  the  majority  of  communication  will  be  provided 
through  a  computer  hookup  with  the  various  users'  terminals  and  mainframes. 

The  communication  computer  must  have  a  multi-tasking  and  multi- 
programming  operating  system.  It  must  permit  many  simultaneous  users  to 
rapidly  access  the  various  automatic  test  program  generators  (ATPC), 
translators,  and  data  bases. 

2.2  STANDARD  DOCUMENTATION 

The  standard  documentation  required  in  the  Facility  are  many  and 
varied;  in  general  they  will  consist  of  all  the  documents  needed  to  contract 
for  and  to  develop  high  quality,  cost  effective  test  program  sets.  The 
current  status  of  identified  standard  documentation  is  shown  in  appendix  A. 
To  improve  the  dissemination  and  currency  of  the  documents,  many,  if  not 
all,  should  be  available  through  a  data  base  management  system  (DBMS)  as 
well  as  hard  copy.  The  following  provides  a  description  of  the  type  of 
standard  documents  that  are  required: 

(a)  Facility  Guide  and  Training  Course  -  will  provide  a  description  of 
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what  is  contained  in  the  library  with  instructions  on  how 
to  access  and  use  the  various  items. 

(b)  Test  Program  Set  Acquisition  Guide  -  will  provide  a  "how-to" 
description  of  TPS  acquisition.  The  guide  should  contain  flow 
charts  that  indicate  when  the  tasks  should  be  completed,  who  should 
accomplish  the  task,  and  what  supporting  documentation  is  available. 
The  guide  should  be  structured  to  match  various  acquisition 
scenarios,  such  as  concurrent  with  the  prime  system  contract 
award,  after  prime  system  award,  and  after  the  prime  system  is 
fielded . 

(c)  Design  for  Testability  Guide  -  will  provide  design  techniques  for 
use  by  the  weapon  system,  prime  system  and  automatic  test 
equipment  designers  to  make  testing  easier,  thereby  reducing  TPS 
complexity  and  cost. 

d)  Test  Requirement  Document  (TRD)  Standard  -  will  provide  a 
standard  that  specifies  what  type  data  must  be  acquired  for  TPS 
development,  when  it  is  needed,  and  the  format  the  data  must  be 
in. 

e)  Model  Unit  Under  Test  (UUT)  Test  Requirements  Document  (TRD) 
Statement  of  Work  (SOW)  -  will  provide  an  on-line  standard  model 
SOW  and  appropriate  contract  data  requirements  list  (CDRL),  as 
well  as  data  item  descriptions  (DID's)  for  incorporation  into  prime 
system  contracts  to  acquire  the  unit  under  test  (UUT)  TRD  data  as 
part  of  the  prime  system  contract  or  after  the  fact.  The  SOW  will 
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be  tailored  for  specific  UUT's  through  queries  and 
reference  to  boilerplate  contained  in  the  data  base. 

(f)  Model  Test  Program  Set  (TPS)  Statement  of  '.V  o  r  k  (SOW)  -  will 
provide  an  on-line  standard  model  TPS  SOW  and  DID's  that  can  be 
used  to  contract  for  the  TPS  as  part  of  the  prime  system  contract 
or  as  a  separate  contract.  The  SOW  will  be  tailored  through  queries 
and  reference  to  boilerplate  contained  in  the  data  base. 

(g)  Model  Test  Program  Set  (TPS)  Specifications  -  will  provide  on-line 
model  system  and  performance  specifications  that  can  be  tailored  to 
define  the  TPS  requirements  through  user  queries. 

(h)  ATLAS  Standard  -  will  provide  copies  of  IEEE  Std  716-1982  Common 
ATLAS  which  is  the  DOD  directed  standard  language  for  preparing 
test  programs. 

(i)  Other  Languages  -  will  provide  copies  of  manuals  covering  languages 
in  widespread  Army  use,  such  as  EQUATE  ATLAS. 

(j)  Test  Program  Set  (TPS)  Configuration  Management  (CM)  Plans  - 
will  provide  on-line  model  TPS  C.M  plans  that  can  be  easily  tailored 
and  included  in  various  TPS  acquisition  contracts;  Army  depots 
that  will  be  maintaining  the  TPS  may  also  use  a  standard  TPS  CM 
plan . 

(k)  Model  TPS  Integrated  Logistic  Support  (ILS)  Plan  -  will  provide  an 
on-line  computer  program  that  through  user  query  and  reference  to 
boilerplate  will  generate  a  tailored  TPS  ILS  plan. 
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(l)  Model  TPS  Quality  Assurance  Plan  -  will  provide  an  on-line  computer 
program  that  will  generate  a  tailored  TPS  quality  assurance  plan  through  user 
query  and  reference  to  boilerplate. 

(m)  Model  TPS  Request  For  Proposal  (RFP)  -  will  provide  an  on-line  computer 
program  which  embodies  Army  policy  with  respect  to  TPS  procurement.  A 
TPS  Development  RFP  can  be  developed  through  user  query  and  reference  to 
boilerplate. 

(n)  TPS  Style  Guide  -  will  provide  a  Test  Program  Style  Guide  outlining 
common  format,  flow  charts,  etc.,  to  aid  in  reducing  the  diverse  means  of 
documenting  TPS.  A  common  style  should  reduce  the  time  and  cost  to 
maintain  future  TPS. 


2.3  Programming  Aids 

Programming  Aids  are  defined  as  a  group  of  data  base  systems  that 
provide  information  to  be  used  in  developing  test  program  sets.  Included 
also  are  data  bases  that  are  part  of  a  repairable  management  system.  All  of 
the  data  bases  will  be  accessable  through  remote  terminals.  If  required, 
special  access  codes  can  be  used  to  restrict  contractor  use  of  data  bases  that 
contain  proprietary  data  provided  by  other  companies.  The  current  status  of 
identified  programming  aids  is  shown  in  Appendix  A. 
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computer  aided  system  for  collecting,  organizing  and  saving 
data  about  ATE  and  TPS  usage,  effectiveness  and  support  cost. 

(f)  TPS  Acquisition  Data  Collection  System  -  will  provide  a  computer 

aided  system  for  collecting,  allocating  and  storing  data  about 
manpower,  material  and  costs  of  TPS  development.  Included 
also  will  be  Army  cost  for  preparing  request-for-proposals 
(RFP's),  conducting  source  selection,  contract  award  and 
contract  monitoring. 

(g)  Library  of  ATLAS  Procedures  -  will  provide  a  library  of  ATLAS 

procedures  to  be  used  in  developing  a  TPS.  The  procedures 
will  aid  in  standardizing  the  resulting  TPS  and  simplifying  the 
coding  process. 

(h)  Unit  Under  Test  (UUT)  versus  Automatic  Test  Equipment  (ATE) 

and  Interface  Test  Adapter  (ITA)  Matching  Algorithm  -  will 
provide  a  computer  data  base  system  that  will  aid  in  matching 
new  UUT  testing  requirements  with  existing  ATE  and  ITA. 

(i)  Computer  Aided  Design  (CAD)  for  Interface  Test  Adapters 

(ITA's)  -  will  provide  an  on-line  CAD  system  that  will  support 
the  design  of  ITA's. 

(j)  Graphics  Development  Aids  -  will  provide  a  computer  aided 

system  to  assist  in  development  of  software  that  will  provide  a 
detailed  display  of  the  testing  flow  to  the  ATE  operator. 

(k)  TPS  Fault  Isolation  Models  -  will  provide  a  computer  system  to 

aid  in  predicting  the  fault  isolation  potential  for  TPS's  to  be 
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The  following  provides  a  description  of  the  type  of  programming  aids 
that  are  required: 

(a)  TPS  Life  Cycle  Cost  (LCC)  Prediction  Model  -  will  provide 
mathematical  models  for  estimating  total  cost  of  developing  and 
maintaining  TPS's  over  the  life  of  a  weapon  or  prime  system. 

(b)  TPS  Development  Cost  Models  -  will  provide  mathematical  models  to 
estimate  cost  of  developing  TPS's  during  the  conceptual  and 
validation  phases  of  weapon  and  prime  system  development. 

(c)  TPS  Schedule  and  Cost  Tracking  System  -  will  provide  a  system 
that  can  easily  track  current  performance  and  cost  against  predicted 
cost.  The  system  will  also  provide  feedback  to  update  the  cost 
prediction  models. 

(d)  Unit  Under  Test  (UUT)  Failure  Data  Collection  System  -  will 
provide  a  computer  aided  system  for  collecting,  organizing  and 
storing  data  on  type  and  frequency  of  UUT  failures.  The  system 
should  also  track  and  provide  an  analysis  of  retest  -  OK  (RTOK) 
and  cannot  duplicate  (CND)  actions.  The  total  analysis  should  be 
automatically  completed  by  grouping  common  classes  of  faults  as  well 
as  faults  identified  against  a  specific  serial  numbered  shop 
replacement  unit  (SRU)  or  line  replacement  unit  (LRU).  The  data 
gathering  aspect  of  this  can  be  automated  as  part  of  the  ATE 
operating  system. 

(e)  ATE/TPS  Operations  Data  Collection  System  -  will  provide  a 
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used  in  developing  test  specifications. 

(l)  TPS  Quality  Assurance  -  will  provide  computer  quality  assurance 
systems  to  aid  in  developing,  validating  and  verifying  (VSV)  TPS. 
The  models  should  permit  assessment  at  several  different  points  in 
the  development  process.  The  first  assessment  shall  be  conducted 
prior  to  coding  the  test  program. 

(m)  Workload  Analysis  System  -  will  provide  as  part  of  a  repairable 
management  system  an  on-line  data  system  that  consists  of 
classification  and  distribution  profiles  of  repairables  and  matches 
these  profiles  to  the  available  maintenance  assessment  required  to 
test  and  repair  the  failed  UUT. 

(n)  ATE/TPS  Operation  Model  -  will  provide  as  part  of  a  repairable 
management  system  a  model  for  estimating  the  ATE  Software 
Development  and  Support  Facility  workload,  turnaround  time,  etc. 

(o)  Depot  and  General  5upport  (CS)  ATE  Shop  Scheduling  System  -  will 
provide  as  part  of  .  epairable  management  system  an  on-line 
computer  program  that  will  accept  user  specified  constraints  and 
then  provide  a  repair  schedule  that  guarantees  optimum  shop 
throughput . 

(p)  TPS  Developer  Configuration  Status  Accounting  System  (CSAS)  - 
will  provide  an  on-line  computer  program  and  a  set  of  procedures 
that  will  permit  the  Army  or  contractor  TPS  developer  to  keep  track 
of  the  UUT,  ATE  and  TPS  configuration  during  the  TPS 
development  phase. 
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(q)  Army  TPS  Management  Configur ation  Status  Accounting  System 
(CSAS)  -  will  provide  an  on-line  computer  program  and  a  set  of 
procedures  that  will  permit  the  Army  organizations  responsible  for 
tracking  and  maintaining  the  TPS  to  keep  track  of  the  UUT,  ATE 
and  TPS  configuration  after  deployment.  The  Army  TPS 
management  CSAS  will  not  track  some  of  the  milestones  included  in 
the  developer  CSAS  such  as  interim  changes  during  quality 
assurance  and  validation  and  verification  checks;  however,  it  will 
contain  additional  information  such  as  TPS  physical  location  and 
status  of  engineering  change  proposals  (ECP's)  that  affect  the  T°S. 

(r)  Shop  Testing  Capabilities  System  -  will  provide  as  part  of  a 
repairable  management  system  an  on-line  data  system  that  will 
display  an  assessment  of  the  shop  testing  capabilities.  The 
assessment  will  indicate  what  UUT's  can  be  tested  with  the  assigned 
ATE  and  TPS  based  on  the  current  configuration  of  ATE,  TPS  and 
UUT.  It  also  will  provide  an  assessment  based  on  degraded  ATE's 
or  ITA's  capabilities  due  to  failures.  The  data  base  can  be 
established  to  obtain  automatic  updates  from  the  command 
configuration  status  accounting  system. 

(s)  Deficiency  Reporting  and  Feedback  System  -  will  permit  a  rapid 
transmission  of  TPS  deficiencies  to  a  central  organization.  The 
system  should  also  provide  for  a  rapid  feedbacK  on  workaround 
procedures  and  the  schedule  for  deficiency  correction. 
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(t)  Word  Processor  -  provides  a  word  processor  computer  program  for 
preparing  and  updating  the  test  proposal  instructions  (TPI's).  The 
word  processor  will  also  be  available  to  update  the  various  standard 
documentation  included  within  the  Facility. 

2.4  Programming  Tools 

Programming  tools  are  defined  as  a  group  of  computer  based  systems 
that  are  used  airectly  by  the  programmers  to  develop  test  programs.  There 
are  many  existing  tools  that  perform  similar  functions;  therefore,  one  of  the 
major  tasks  in  this  area  will  be  to  identify  a  specific  tool  or  a  family  of 
related  tools  for  inclusion  in  the  Facility.  The  following  provides  a 
description  of  the  programming  tools  that  are  required: 

(a)  Digital  Automatic  Test  Pattern  Generator  (  AT P G )  -  provides  a 
family  of  computer  programs  that  will  analyze  a  digital  circuit 
description  of  a  UUT  and  generate  a  test  program  for  that  UUT. 

(b)  Digital  Simulator  -  provides  a  family  of  computer  programs  that  will 
evaluate  the  fault  detection  effectiveness  of  a  digital  test.  The 
program  should  also  generate  test  responses  and  fault  isolation  data. 

(c)  Analog  Automatic  Test  Program  Generator  (  ATPG)  -  provides  a 
computer  program  that  will  analyze  an  analog  circuit  description  and 
generate  a  test  program  for  that  UUT. 

(d)  ATLAS  Flowchart  Generator  -  provides  a  computer  program  for 
analyzing  a  test  program  written  in  ATLAS  and  automatically 
generates  a  pictorial  and  commented  flowchart  of  the  program. 
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(e)  Text  Editor  -  provides  an  on-line  computer  program  for  viewing  and 
modifying  computer  programs. 

(f)  IEEE  Std  716,  Common  ATLAS  Compiler  and  Syntax  Checker  - 
provides  a  portable  IEEE  Std  716  ATLAS  Compiler  that  will  check 
the  syntax  of  ATLAS  programs,  provide  appropriate  warning  and 
error  messages,  and  translate  the  716  ATLAS  code  into  an 
intermediate  code  or  into  a  format  suitable  for  execution  on  a 
specific  test  station. 

(g)  EQUATE  ATLAS  Compiler  and  Syntax  Checker  -  provides  an 
EQUATE  ATLAS  Compiler  that  will  check  the  syntax  of  EQUATE  test 
programs,  provide  appropriate  warning  and  error  messages,  and 
translate  the  EQUATE  ATLAS  into  a  format  suitable  for  execution  on 
a  AN/ USM  410. 

(h)  Other  compilers  and  syntax  checkers  -  provide  the  additional 
compilers  and  syntax  checkers  that  are  required  to  support  the 
assigned  TPS. 

(i)  Translators  -  provide  a  family  of  translators  capable  of  translating 
test  programs  written  on  one  tester  to  operate  on  another  tester  or 
from  one  language  to  another.  For  example,  AN/USM  410  ATE  to 
GENRAD  2225  ATE,  Chrysler  DSETS  Language  to  IEEE  Std  716 
Common  ATLAS,  EQUATE  ATLAS  Language  to  IEEE  Std  716  Common 
ATLAS,  IEEE  Std  716  Common  ATLAS  to  EQUATE  ATLAS,  etc. 

(j)  Failure  Vtodes  Effects  Analysis  (FMEA)  to  ATLAS  Translator  - 
provides  an  on-line  computer  program  that  will  translate  the  FMEA 
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failure  signatures  directly  into  the  diagnostic  portion 
of  an  IEEE  Std  716  Common  ATLAf  test  program. 

(k)  ATLAS  Composing  Terminal  -  provides  an  on-line  computer  program 
that  through  templates  or  some  other  means  lead  a  technician 
through  the  process  of  developing  IEEE  Std  716  ATLAS  test 
programs.  The  system  should  accept  test  requirement  document 
(TRD}  data  and  develop  a  test  program  as  well  as  accept  detailed 
source  data  and  generate  both  a  TRD  and  a  test  program. 

(l)  Self  Learning  TP  Generator  -  provides  a  self  learning  test  program 
generator  using  knowledge  based  system  (KBS)  and  artificial 
intelligence  (Al)  technology.  The  self  learning  generator  will  be 
able  to  automatically  improve  the  test  program  based  on  actual 
testing  data. 

(m)  Test  Program  Development  Stations  -  provide  the  necessary  test 
program  development  stations,  including  EQUATE  ATLAS  and 
Common  ATLAS  Compilers,  to  permit  initial  development  of  test 
programs  without  using  the  complete  ATE  stations. 

(n)  ATE  Simulator  -  will  be  provided  to  conduct  off-line  testing  for 
logic  and  parameter  errors  during  execution  of  ATLAS  programs. 
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1.0 


SCOPE 


1.1  Purpose 

This  preliminary  design  specification  describes  the 
hardware,  software,  and  documents  to  be  installed  in  one  or  more 
Army  facility  to  provide  support  for  the  development,  mainte¬ 
nance,  and  management  of  functional  and  diagnostic  test  programs 
used  with  Automatic  Test  Equipment  (ATE). 


2.0  APPLICABLE  DOCUMENTS 


2.1  Government  Documents 

The  following  documents  of  current  issue  form  a  part  of  this 
specification  to  the  extent  specified  herein. 


2.2  Non-Government  Documents 

The  following  documents  of  current  issue  form  a  part  of  this 
specification  to  the  extent  specified  herein. 

IEEE  Standard  716,  Common  ATLAS 


3.0  REQUIREMENTS 


3«1  System  Definition 

The  system  shall  consist  of  an  aggregate  of  hardware, 
software,  and  documentation  which  shall  support  the  acquisition, 
development  management  and  maintenance  of  Test  Program  Sets  (TPS) 
within  the  Army.  The  system  may  be  implemented  as  a  single  fa¬ 
cility  or  a3  multiple  facilities  depending  on  the  location  and 
workloads  to  be  supported. 


3.1.1  General  definition 

The  system  shall  consist  of  a  communication  subsystem,  an 
acquisition  support  subsystem,  an  operational  support  subsytem, 
and  a  TPS  development  and  maintenance  support  subsystem.  The 
communication  subsystem  shall  permit  the  support  subsystems  to  be 
utilized  by  remote  users.  Each  of  the  support  subsystems  shall 
consist  of  one  or  more  computer  system,  software  packages,  and 
documentation . 


3.1.2  Missions 


The  system  shall  support  the  following  missions: 

o  Act  as  focal  point  for  TPS  acquisition  problems 

o  Provide  a  means  to  predict  and  track  cost  for  TPS 

development  and  operation 

o  Provide  guidance  in  preparation  of  TPS  acquisition  docu¬ 
ments 

o  Provide  a  means  to  consolidate  TPS  users'  problems  for 

transmission  to  development,  agencies 

o  Provide  Configuration  Status  Accounting  (CSAS)  capabili¬ 
ties 

o  Provide  a  family  of  automatic  test  program  generators  and 
simulators 

o  Provide  a  family  of  ATLAS  compilers  and  translators 

o  Provide  a  family  of  ATLAS  composing  terminals  and  pro¬ 

gramming  stations 

o  Provide  a  family  of  programming  aids  and  tools 

o  Provide  TPS  shop  management  aids 


3.1.3  System  diagram 

The  overall  system  consists  of  the  following  hardware  items: 
o  Communications  network 

o  Acquisition  and  management  computer  system 

o  Digital  ATPG  development  and  maintenance  computer  system 

o  Analog  test  development  and  maintenance  computer  system 

The  interconnections  between  these  items  are  shown  in  figure  3-1  • 
Within  each  of  these  hardware  items  are  software  packages  and 
documentation  particularly  applicable  to  the  functions  provided 
by  the  computer  systems.  Figures  3-2,  3-3,  and  3-4  show  these 
packages  and  the  data  interconnections  between  them  for  each  of 
the  computer  systems. 
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FIGURE  3-1  SYSTEM  DIAGRAM 
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FIGURE  3-3 

DIGrTAL  TPS  SUPPORT  SOFTWARE  SYSTEM 


FIGURE  3-4 

ANALOG  TPS  SUPPORT  SOFTWARE  SYSTEM 


3-1.4  Interface  definitions 


There  are  three  types  of  interfaces  provided  by  the  system 
as  follows: 

o  Interaction  with  users  through  keyboards  and  CRT  termi¬ 
nals 

o  Printed  reports  generated  by  the  system 

o  Communication  of  data  to  ATS  and  other  computers  using 
magnetic  media  or  communications  lines 

The  interfaces  of  each  functional  software  package  or  part 
thereof  are  shown  in  Table  3-1-  The  interfaces  between  the 
software  packages  are  illustrated  in  Figures  3-2,  and  3-3* 


TABLE  3-1 


Function 


Software  Package 


Facility  Guide  and  Course 
TPS  Acquisition  Data 

Collection  System 


TPS  LCC  Prediction  Model 
TPS  Development  Cost  Model 
TPS  Schedule  &  Cost  Tracking 
System 


TPS  Acquisition  Guide 

Design  for  Testability  Guide 

TRD  Standard 

Model  SOW  for  OUT  TRD 

Model  SOW  for  TPS 

Model  TPS  Specifications 

IEEE  ATLAS  Standards 

Army  Fielded  Test  Languages 

Model  TPS  CM  Plan 

Model  TPS  ILS  Plan 

Model  TPS  QA  Plan 

Model  TPS  RFP 

TPS  Fault  Isolation  Model 

TPS  QA  Model 

Matching  Algorithms 

Workload  Analysis  System 

Word  Processor 
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CRT 

Print 
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•  — 

-- 

YES 

— 
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YES 

-- 

— 

YES 

-- 

-- 

YES 
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-- 
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-- 

YES 

-- 

-  - 

YES 

-- 

-- 

YES 

-- 
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YES 

-- 

-- 

YES 

— 

YES 

YES 

-- 

YES 

YES 

-- 

YES 

YES 

— 

YES 

YES 

— 

YES 

YES 

4  UUT  Failure  Data  Collection 


System 

YES 

YES 

YES 

ATE/TPS  Operations  Data 

Collection  System 

YES 

YES 

YES 

Deficiency  Reporting  A 

Feedback  System 

YES 

YES 

-- 

5 

TPS  Developer  CSAS 

YES 

YES 

_  — 

Army  TPS  Management  CSAS 

YES 

YES 

6 

Digital  ATPG 

YES 

YES 

YES 

Digital  Simulator 

YES 

YES 

YES 

Analog  ATPG 

YES 

YES 

YES 

7 

IEEE  C/ATLAS  Compiler  A 

Syntax  Checker 

YES 

YES 

YES 

EQUATE  ATLAS  Compiler  A 

Syntax  Checker 

YES 

YES 

YES 

Fielded  Test  language  Compilers 
A  Syntax  Checkers 

YES 

YES 

YES 

Translators 

YES 

YES 

YES 

FMEA  to  ATLAS  Translator 

YES 

YES 

YES 

8 

ATLAS  Composing  terminal 

YES 

YES 

_ 

Self  Learning  Test  Program 
Generator 

YES 

YES 

YES 

Test  Program  Development 
Stations 

YES 

YES 

YES 

9 

TPS  Style  Guide 

YES 

—  — 

CAD  for  ITA 

YES 

YES 

— 

Graphics  developments  Aids 

YES 

YES 

TPS  Fault  Isolation  Models 

YES 

YES 

— 

TPS  Quality  Assurance  Tools 

YES 

YES 

— 

ATLAS  Flowchart  Generator 

— 

YES 

-- 

Text  Editor 

YES 

— 

— 

ATE  Simulator 

YES 

YES 

S^lf  Learning  Test  Program 
Generator 

YES 

YES 

YES 

10 

ATE/TPS  Operation  Model 

YES 

YES 

_  _ 

Depot  A  GS  Shop  Scheduling 
System 

YES 

YES 

YES 

Shop  Testing  Capabilities 
System 


YES 


YES 


YES 


3.2  Performance  Characteristics 

The  system  shall  support  each  of  the  missions  described  in 
paragraph  3.1.2  by  timely  responses  to  terminal  key  entries,  gen¬ 
erating  reports  requested  in  a  timely  manner,  and  generating 
periodically  those  reports  required  on  a  periodic  basis.  The 
responses  and  reports  shall  meet  the  requirements  of  the  missions 
as  described  below. 


3*2.1  Focal  Point  for  TPS  Acquisition  Problems 

The  system  shall  provide  interfaces  for  the  collection  of 
data  about  TPS  acquisition  events,  the  data  base  system  required 
to  support  that  data,  and  the  capability  to  respond  to  queries  on 
that  data  and  generate  reports  describing  that  data.  It  shall 
provide  the  means  of  collecting  the  data  from  computer  files 
maintained  by  the  TPS  Schedule  and  Cost  Tracking  system,  tele¬ 
phone  calls,  conferences,  written  correspondence ,  and  technical 
reports.  The  system  shall  provide  detailed  and  summary  reports 
of  any  TPS  acquisition  experience  gathered  by  cost,  schedule, 
acquisition  strategy,  UUT  technology,  ATE  type,  complexity,  or 
other  factors  which  may  be  useful  in  planning  or  implementing  a 
new  TPS  acquisition.  It  shall  have  available  all  standards  ap¬ 
plicable  to  acquisition  of  TPSs,  and  a  description  of  the  current 
aids  and  tools  which  may  be  used  in  TPS  acquisition  and  develop¬ 
ment.  The  full  capability  and  operation  of  the  system  shall  be 
documented  in  a  Facility  Guide,  and  be  available  in  the  form  of  a 
training  course. 


3.2.2  Prediction  And  Cost  Tracking  Of  TPS  Development 

The  system  shall  accept  data  concerning  proposed  TPS 
development  factors  and,  by  using  a  TPS  Development  Cost  Model, 
shall  predict  the  cost  of  developing  the  TPSs  and  minimum 
development  time.  It  shall  also  accept  data  concerning  the  pro¬ 
posed  utilization  of  the  TPSs,  either  from  the  data  files  of  the 
ATE/TPS  Operation  Model  or  from  manual  entries,  and  predict  the 
Life  Cycle  Cost  of  acquiring  and  operating  the  TPSs.  The  system 
cost  models  shall  be  periodically  updated  based  on  the  data 
available  from  the  data  collection  system.  Access  to  these 
models  shall  be  provided  directly  to  acquisition  managers  or  oth¬ 
er  users  through  a  remote  CRT  terminal  or  remote  Job  entry  termi¬ 
nals.  The  system  shall  also  provide  support  for  the  tracking  of 
TPS  development  schedules  and  costs.  This  support  shall  include 
data  entry  screens  for  ease  of  entry  of  schedule  and  cost  plans, 
critcal  path  method  analyses  of  these  plans,  reports  of  the  plans 
and  analyses,  data  entry  and  query  screens  for  the  entry  of 
current  TPS  development  schedule  and  cost  statuses,  and  reports 
on  these  statuses. 
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3.2.3  Preparation  of  TPS  Acquisition  Documents 

The  system  shall  maintain  and  provide  copies  as  requested  of 
TPS  related  guides,  standards,  and  model  documents  including  at 
least  the  following: 

o  TPS  Acquisition  Guide 

o  Design  For  Testability  Guide 

o  Test  Requirement  Document  (TRD)  Standard 

o  ATLAS  Language  Standard 

o  Model  Statement  of  Work  for  Test  Requirement  Documents 
o  Model  Test  Program  Set  Specifications 

o  Model  TPS  Configuration  Management  Plan  for  development 
projects 

o  Model  TPS  Integrated  Logistics  Support  Plan 
o  Model  TPS  Quality  Assurance  Plan 


o  Model  Request  for  Proposal  for  acquiring  TPSs 

These  documents  shall  be  supplemented  by  computer  aids.  Among 
the  aids  shall  be  word  processing  capability  which,  in  conjunc¬ 
tion  with  the  model  documents ,  provides  a  "fill  in  the  blanks" 
capability  for  developing  acquisition  documents.  The  system 
shall  provide  support  for  the  determination  of  the  number  of  TPSs 
to  order,  and  which  versions  of  the  ATE  for  which  they  are  to  be 
provided.  This  support  will  be  provided  in  the  form  of  a  Work 
Load  Analysis  System,  a  matching  algorithm  between  UUT  and  exist¬ 
ing  ITAs,  and  an  ATE/TPS  Operation  Model  of  the  existing  testing 
system.  These  systems  shall  accept  data  from  the  Shop  Testing 
Capability  System  files,  the  ATE/TPS  Operations  Data  Collection 
Systems  and  user  manual  entry.  Based  on  this  data,  they  will 
predict  the  number  of  TPSs  of  each  UUT  required  and  relevant 
characteristics  required  to  make  the  most  effective  use  of 
current  capabilities.  Access  to  these  models  shall  be  provided 
directly  to  acquisition  managers  or  other  users  through  a  remote 
CRT  terminal  or  remote  Job  entry  terminal. 


3.2.4  Consolidation  of  TPS  Problems 

The  system  shall  provide  the  means  of  accepting  deficiency 
report  data  either  through  a  remote  terminal  or  through  transcit- 
ed  documents.  The  system  shall  validate  the  data  against  the 
deployed  ATE  and  TPS  configuration  items,  determine  the  individu¬ 
als  responsible  for  their  corrections,  distribute  the  deficiency 
reports,  provide  reports  classifying  them  and  grouping  them,  and 
provide  tracking  services  through  their  resolution.  In  addition 
to  collecting  data  on  deficiency  reports,  the  system  shall 
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collect  data  on  the  operation  of  the  deployed  ATE  and  TPSs.  It 
shall  include  the  means  of  collecting  ATE  data  log  information 
and  processing  it  to  determine  utilization  of  each  deployed  ATE 
and  TPS,  availability  history  of  ATE,  and  number  and  type  of 
failures  of  tested  UUT  found.  This  data  along  with  summary  data 
about  deficiency  reports  shall  be  provided  in  monthly  reports  by 
the  system. 


3*2.5  ATE  And  TPS  Configuration  Status  Accounting 

The  system  shall  provide  support  for  configuration  status 
accounting  of  operational  ATE  and  TPS  in  the  following  areas: 

o  On-line  support  for  the  data  entry,  data  base  query,  and 
data  base  update  of  identification  and  description  of  ATE 
and  TPS  configuration  items 

o  The  generation  of  configuration  status  accounting  reports 
and  other  reports  required  to  support  TPS  development  ana 
maintenance  decisions 

o  On-line  support  and  the  generation  of  appropriate  reports 
for  the  tracking  of  engineering  changes  to  ATE  and  TPSs 

o  On-line  support  and  the  generation  of  appropriate  reports 
for  the  tracking  of  deployment  of  physical  configuration 
items  within  the  Army  (including  shipments) 

In  addition  to  providing  support  for  operational  ATE  and  TPS,  the 
system  shall  provide  a  similar  capability  for  those  responsible 
for  the  development  of  a  set  of  TPSs. 


3.2.6  Automatic  Test  Program  Generators  and  Simulators 

The  system  shall  provide  digital  test  program  engineers  with 
on-line  terminal  access  to  state-of-the-art  digital  simulators 
and  digital  test  program  generators.  These  tools  shall  automati¬ 
cally  or  semi -automatically  generate  digital  functional  tests, 
and  data  for  fault  signature  and  guided  probe  diagnostics.  They 
shall  also  provide  a  measure  of  the  portion  of  failures  which 
will  be  detected  by  the  test  and  the  size  distribution  of  the 
ambiguity  groups  identified  through  the  fault  signature  failure 
isolation  data.  The  access  to  system  shall  also  provide  state- 
of-the-art  analog  simulation  and  test  generation  software.  It 
shall  provide  reference  manuals  and  courses  for  those  not  fami¬ 
liar  with  any  of  these  tools  operations. 
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3-2.7  ATLAS  Compilers  And  Translators 


The  system  shall  provide  test  program  engineers  charged  with 
the  preparation  and  maintenance  of  Army  test  programs  with  off- 
ATE  compilers  for  the  common  languages  used  on  Army  test  sta¬ 
tions.  The  compiler  output  which  are  generated  shall  be  suitable 
for  execution  on  the  appropriate  ATE.  The  system  shall  also  make 
available  any  translators  developed  for  converting  the  source 
language  of  one  ATE  into  that  of  another  ATE  or  for  transforming 
the  output  of  one  compiler  into  a  format  suitable  for  execution 
on  an  ATE  different  from  its  original  target.  These  compilers 
and  translators  shall  be  available  to  the  user  through  a  terminal 
at  his  location.  The  system  shall  have  the  capability  of 
transferring  the  data  to  the  target  ATEs  via  the  appropriate 
media  (magnetic  tape,  cassette,  PROMs,  or  communication  lines). 


3.2.8  Composing  Terminals  And  Programming  Stations 

The  system  shall  provide  an  integrated  set  of  software  pack¬ 
ages  which  support  the  development  of  test  requirement  documents, 
test  programs,  and  test  instructions.  These  packages  shall  in¬ 
clude  templates  and  formatted  screens  for  the  original  data  en¬ 
try,  translation  packages  to  reformat  the  data  for  each  of  the 
three  items,  and  compilers  and  word  processors  for  preparation  of 
the  data  for  final  use. 


3.2.9  Programming  Aids  And  Tools 

The  system  shall  provide  a  set  of  tools  for  a  test  program 
engineer  to  assure  that  the  whole  test  program  is  of  high  quality 
as  follows: 

o  Test  program  design  architecture  and  details  are  ad¬ 
dressed  through  a  TPS  Style  Guide  and  a  library  of  stan¬ 
dard  ATLAS  procedures. 

o  Test  performance  and  ATE  compatibility  is  addressed 
through  TPS  fault  isolation  models,  a  set  of  TPS  Quality 
Assurance  Software  Packages,  and  an  ATE  Simulator. 

o  Interface  adapter  design  is  addressed  through  a  computer 
aided  design  package. 

o  Documentation  quality  is  addressed  with  graphics  develop¬ 
ments  aids,  flow  chart  generators,  word  processors,  and 
text  editors 


3.2.10  ATE/TPS  Shop  Management  Aids 


The  system  shall  on-line  terminal  entry,  update  and  query 
capability  to  Depot  and  GS  shop  managers  for  optimum  utilization 
of  his  testing  capabilities  within  priority  constraints.  He 
shall  be  able  to  update  the  dat.  base  of  shop  capabilities  to 
show  new  resources  obtained,  resources  lost,  or  resources  which 
are  temporarily  unavailable  or  degraded  due  to  failures.  He 
shall  be  able  to  enter  new  items  requiring  testing  as  they  enter 
and  indicate  items  removed  through  testing  or  other  means  and 
changes  in  priority  a3  provided.  The  system  will  furnish  him  an 
optimal  schedule  and  with  stock  room  packing  li3t  requirements. 
It  shall  identify  items  not  testable  with  the  current  capability 
and  will  make  allowance  for  limited  quantities  of  ATS,  interface 
test  adapters,  and  test  program  media. 


3.3  Design  And  Construction 

The  system  shall  be  designed  and  constructed  of  commercially 
available  and  field  proven  hardware  and  software  wherever  that  is 
available. 


3.4  Documentation 

All  hardware  and  software  shall  include  a  complete  set  of 
documentation  suitable  for  training  and  reference  in  its  opera¬ 
tion  and  maintenance. 


4.0  QUALITY  ASSURANCE  PROVISIONS 


4.1  General 

Each  functional  component  of  the  system  and  the  overall  sys¬ 
tem  performance  shall  be  evaluated  with  formal 

tests/verifications  of  performance,  design  characteristics,  and 
operability.  The  following  types  of  tests  and  verifications 
shall  be  applied: 

o  Reliability  Testing  -  The  collection,  recording,  and 
analysis  of  data  concerning  time  between  system  failures 

o  Design  Engineering  Evaluation  -  The  analysis  of  design 
and  test  documents  as  they  are  developed 

o  Qualification  Testing  -  The  carrying  out  of  test  pro¬ 
cedures  on  configuration  items  and  critical  items  to 
qualify  them  for  inclusion  in  the  system 

o  Installation  Testing  And  Checkout  -  Tests  which  assure 
that  the  delivered  and  installed  configuration  and  criti¬ 
cal  items  are  operational  including:  continuity  checking, 
interface  mating,  operability  within  system  environment, 
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support  equipment  compatibility,  and  proper  documentation 


o  Formal  Test  -  Verification  that  the  item  and  system  meets 
all  requirements  and  performance  characteristics  speci¬ 
fied 

Wherever  commercial  items  used,  testing  for  that  item  shall  be 
restricted  to  qualification  testing  and  installation  testing  and 
checkout.  Design  engineering  evaluation  and  formal  test  shall  be 
used  to  assure  that  specially  designed  components  and  the  overall 
system  meet  their  specified  requirements. 


4.2  Quality  Conformance  Inspections 

The  nature  of  the  quality  assurance  inspections  for  each 
functional  system  item  is  contained  in  Table  4-1.  These  inspec¬ 
tions  shall  be  implemented  in  an  order  such  that  installation 
te3ts  and  checking  and  formal  test  are  accomplished  at  the  loca¬ 
tion  of  the  facilities. 


TABLE  4-1  QUALITY  CONFORMANCE  INSPECTION  REQUIREMENTS 


Area 

— 

Reli 

Eng. 

Qual 

Inst 

Form 

Configuration  Item 

abil 

Eval 

if  ic 

alia 

a  1 

ity 

at '  n 

tion 

Test 

1  .  1 

ATE  Support  Facility 

YES 

YES 

— 

YES 

YES 

1.2 

Communications  Network 

YES 

— 

— 

YES 

YES 

1.3 

Acq.  A  Mangement  Computer 

YES 

— 

YES 

YES 

— 

1.4 

Digital  Test  Dev't  Computer 

YES 

— 

YES 

YES 

— 

1.5 

Analog  Test  Dev't  Computer 

YES 

— 

YES 

YES 

-- 

2.  1 

Facility  Guide  and  Course 
TPS  Acquisition  Data 

-- 

YES 

-- 

-- 

YES 

Collection  System 

YES 

YES 

-- 

YES 

YES 

<M 

Csl 

TPS  LCC  Prediction  Model 

YES 

YES 

YES 

TPS  Development  Cost  Model 
TPS  Schedule  4  Cost  Track'g 

“  - 

YES 

-  — 

YES 

YES 

System 

-- 

YES 

-- 

YES 

YES 

1  4  - 


YES 


2.3  TPS  Acquisition  Guide 
Design  for  Testability 

Guide  --  YES 
TRD  Standard  --  YES 
Model  SOW  for  UUT  TRD  --  YES 
Model  SOW  for  TPS  --  YES 
Model  TPS  Specifications  --  YES 
IEEE  ATLAS  Standards  --  YES 
Army  Fielded  Test  Languages  --  YES 
Model  TPS  CM  Plan  --  YES 
Model  TPS  ILS  Plan  --  YES 
Model  TPS  QA  Plan  --  YES 
Model  TPS  RFP  --  YES 


TPS  Fault  Isolation  Model 

_  - 

YES 

— 

YES 

YES 

TPS  QA  Model 

— 

YES 

-- 

YES 

YES 

Matching  Algorithms 

YES 

-- 

YES 

YES 

Workload  Analysis  System 

YES 

YES 

-- 

YES 

YES 

Word  Processor 

— 

YES 

YES 

-  - 

2.4 

UUT  Failure  Data  Collection 
System 

YES 

YES 

YES 

YES 

ATE/TPS  Operations  Data 
Collection  System 

YES 

YES 

YES 

YES 

Deficiency  Reporting  4 
Feedback  System 

YES 

YES 

— 

YES 

YES 

2.5 

TPS  Developer  CSAS 

_  _ 

YES 

_  _ 

YES 

YES 

Army  TPS  Management  CSAS 

YES 

YES 

— 

YES 

YES 

2.6 

Digital  ATPG 

YES 

YES 

_  _ 

Digital  Simulator 

— 

— 

YES 

YES 

— 

Analog  ATPG 

-- 

YES 

YES 

2.7 

IEEE  C/ATLAS  Compiler  4 
Syntax  Checker 

YES 

YES 

EQUATE  ATLAS  Compiler  4 
Syntax  Checker 

.. 

YES 

YES 

Fielded  Test  language  Compilers 

4  Syntax  Checkers 

YES 

YES 

YES 

Translators 

— 

YES 

— 

YES 

YES 

FMEA  to  ATLAS  Translator 

YES 

— 

YES 

YES 

2.8 

ATLAS  Composing  terminal 

YES 

YES 

YES 

Self  Learning  Test  Program 
Generator 

YES 

YES 

YES 

Test  Program  Development 
Stations 

YES 

YES 

YES 
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YES 


9  TPS  Style  Guide 
CAD  for  ITA 

Graphics  developments  Aids 
TPS  Fault  Isolation  Models 
TPS  Quality  Assurance  Tool 
ATLAS  Flowchart  Generator 
Text  Editor 
ATE  Simulator 

Self  Learning  Test  Program 
Generator 

10  ATS/TPS  Operation  Model 
Depot  A  GS  Shop  Scheduling 

System 

Shop  Testing  Capabilities 
System 


-  - 

— 

YES 

YES 

-- 

-- 

YES 

YES 

-- 

— 

YES 

— 

YES 

YES 

-- 

YES 

— 

YES 

YES 

— 

YES 

— 

YES 

YES 

— 

— 

YES 

YES 

— 

-- 

YES 

-- 

YES 

YES 

-- 

YES 

— 

YES 

YES 

-- 

YES 

-- 

YES 

YES 

YES 

YES 

YES 

YES 


YES 


YES 
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